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ABSTRACT 


Computer systems that earn a high degree of trust must be backed by rigorous 
verification methods. A verification system is an interactive environment for writing 
formal specifications and checking formal proofs. Verification systems allow large 
complicated proofs to be managed and checked interactively. We desire evaluation 
criteria that provide a means of finding which verification system is suitable for a specific 
research environment and what needs of a particular project the tool satisfies. Therefore, 
the purpose of this thesis is to develop a methodology and set of evaluation criteria to 
evaluate verification systems for their suitability to improve the assurance that systems 
meet security objectives. A specific verification system is evaluated with respect to the 
defined methodology. The main goals are to evaluate whether the verification system has 
the capability to express the properties of software systems and to evaluate whether the 
verification system can provide inter-level mapping, a feature required for understanding 
how a system meets security objectives. 
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EXECUTIVE SUMMARY 


“Use theory to provide insight; use common sense and intutition where it 
is suitable, but fall back upon the formal theory when difficulties and 

complexities arise. ”t 

Computer systems that earn a high degree of trust must be baeked by rigorous 
verifieation methods. Formal methods deal with formally reasoning about eomputer 
systems and whether those systems offer verifiable proteetion. Without the use of 
verifieation systems, formal verifieation is impraotieal. These tools help to ensure the 
absenee of subversion by automating the proeesses of generating proofs and evaluation 
evidence. Recognition is growing for the value of formal methods in certain area such as 
verifying algorithms and exploring properties of complex interactions. The purpose of 
this paper is to develop evaluation methodology for a set of verification systems that will 
be used to improve the assurance that systems meet security objectives. 

This thesis is divided into three phases: the desktop analysis phase, the hands-on 
phase, and the evaluation phase. First, a list is developed of potential verification 
systems for evaluation. Then a desktop analysis is performed of the candidates where the 
potential verification systems will be analyzed to find out whether they meet a set of 
broad functional requirements (evaluation criteria). Defining evaluation criteria provides 
a means of finding which verification system is suitable for a specific research 
environment and what needs of a particular project the tool satisfies. Therefore, the 
selected verification system(s) are the ones that best satisfy the evaluation criteria. 

A hands-on study or empirical study of the selected verification system is 
performed. First, a simplified version of a complex computer security related problem is 
constructed. Then a formally security policy and a formal top level specification is 
developed in terms of the selected verification system. From there, a mapping of the 
FTLS to the formal security policy model is attempted. The major goal of this paper is to 


1 From Gries, David. The Science of Programming. 1981, pages 164 - 165 
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illustrate whether the verifieation system ehosen for evaluation ean demonstrate inter¬ 
level mapping, a feature that is required in later applieations. 

The verifieation system that is ehosen for analysis is evaluated based on a set of 
questions. These questions are: how well does the system deseribe the seeurity poliey 
and the FTLS, how mueh assuranee is provided, and how easy is it to prove that the 
FTLS implements the poliey? The main features of the verifieation system that are 
analyzed to answer how well the verification system described the FTLS and the formal 
security policy model are the system’s expressiveness, its consistency checking 
mechanisms, and any features that help in improving the specifications. Whether the 
system provides mechanisms for checking semantic and logical consistency can help to 
determine the level of assurance provided. Lastly, decision and inference strategies of 
the system’s theorem prover, the ease of use of the interface, and the implementation 
language of the theorem prover are the main features that can establish how easy it is to 
prove that the FTLS satisfies the policy. The main concern, however, is that the system 
must first demonstrate the ability to provide inter-level mapping before a thorough 
analysis can be constructed. 

Our empirical study of the verification system that we chose to evaluate paves the 
way for future research of other verification systems. The methodology used in this 
thesis can be followed for the analysis of the next selected verification system. The inter¬ 
level mapping work that has been done in this paper demonstrates new research that has 
not been addressed in any PVS documentation that we have read. Therefore, the 
problems we have come upon as well as the ideas we have brought forth should be 
assessed and used in future work. 

“Ifyou wish to derive the most profit from your effort, look out for such features 
of a problem at hand as may be useful in handling the problems to come. A 
solution that you have obtained by your own effort or one that you have read or 
heard, but have followed with real interest and insight, may become a pattern for 
you, a model that you can imitate with advantage in solving similar problems.... 


2 Polya, George. Mathematical Discovery: On Understanding, Learning and Teaching Problem 
Solving, Wiley, eombined edition, 1981, prefaee 



I. INTRODUCTION 


A. PURPOSE 

Computer systems that earn a high degree of trust must be backed by rigorous 
verification methods. Formal methods deal with formally reasoning about computer 
systems and whether those systems offer verifiable protection. “The IEEE definition of 
verification is, confirmation by examination and provisions of objective evidence that 
specified requirements have been fulfilled”. [Asc02] Eormal verification is impractical 
without the use of tools such as model-checkers and theorem provers. These tools help to 
ensure the absence of subversion by automating the processes of generating proofs and 
evaluation evidence. Recognition is growing for the value of formal methods in certain 
areas such as verifying algorithms and exploring properties of complex interactions. 
Tools are available that allow large complicated proofs to be managed and checked 
interactively. However, many in the computer science community agree that these 
verification systems may not make the activity of formal proof easy and may not be easy 
to use. 

The main classes of verification tools include theorem proving (both automatic 
and human-assisted) and model checking approaches. The integrations of both these 
approached is advocated and exemplified in current verification tools. Tool support is 
important in formal methods, however it is a very skilled and time consuming activity. 
There are theorem provers that integrate inductive proof techniques, general rewrite 
procedures, model checking, propositional provers, linear arithmetic, other decision 
procedures, tactic facilities, execution capabilities, enhanced static checking, lemma 
generation, and computer algebra systems (See glossary). Some of the systems that are at 
least partially successful in combining these techniques are PVS, HOE, EVES, and 
ACE2. Another development direction of importance is the automation of verification 
procedures most of which are dependent on highly skilled user input. In addition, 
increased automation of induction proofs would be a great gain for the verification 
systems. Verification tools can be shallower but messier than general mathematical 
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proofs, therefore this area of researeh is being pursued actively to provide solutions to 
these problems. 

In this thesis, an evaluation methodology was developed and a selected 
verification system was evaluated for its ability to improve the assurance that systems 
met certain security objectives. Systems are built to implement some security policy, 
however the end product can be flawed. For example, security policies can be 
inconsistent and the implementation of the system may not truly reflect the policies. 
Formal specifications and verification tools can be used to achieve a more secure system 
and to provide higher assurance that the system meets the requirements. 

Several steps are followed during the assurance process to reveal any unspecified 
functionality and to create verifiable protection: 

(1) Establish a security policy 

(2) Develop a Formal Security Policy Model and prove that is meets its own 
requirements 

(3) Create a formal top level specification (FEES) 

(4) Eormally map the EELS to the Security Policy Model 

(5) Develop a detailed design of the system 

(6) Map the implementation or source code to the PELS. 

Pirst, security policies are created to cover all aspects of protection of 
organizational assets. Some of these policies are then represented in a PormaE Security 
Policy Model. Ehis model is represented mathematically using precise mathematical 
logic or a specification language that has formal well-defined semantics. Ehis can be 
done at several levels of abstraction. A verification system may be used to represent the 
mathematical model of the security policy. 

A formal top level specification (PELS) is created using notations derived from 
formal logic to describe assumptions about the world in which a system will operate, 
requirements that the system will have, and a design to meet those requirements. Ehe 

3 Mathematical 
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FTLS may also be represented in the language of the verifieation system. A detailed 
design of the system is developed from the FTLS using preeisely defined semanties. 

Proofs are then developed to show that the more eonerete levels logieally imply 
the more abstraet oriented levels. These proofs are repeatable by third parties. A semi- 
automatie theorem prover is used to make sure that all of the proofs are valid. Lastly, 
souree code is mapped to the FTLS. This mapping is made possible by the design 
process. The implementation effectively uses abstraction, layering, and information 
hiding. The implementation should map to the FTLS so there is no unintended 
functionality. The five levels used in Formal Methods can be seen in Figure 1. 

The FTLS and the security policy model are both represented using the language 
of a verification system. The verification system examined in this study will be evaluated 
based on how well it can describe the security policy and system designs, the level of 
assurance provided, and how easy it is to prove the design implements the policy. At 
least one simplified version of this complex problem will be established and the 
verification system will be evaluated based on this sample problem. 

B. METHODOLOGY 

This thesis was divided into three phases: the desktop analysis phase, the hands- 
on phase, and the evaluation phase. The initial phase also known as the survey or desktop 
analysis phase, consisted of developing a list of potential verification system candidates 
for evaluation and filtering out the verification systems that did not meet a set of broad 
functional requirements. These requirements were used to construct the set of evaluation 
criteria with which the “ filtering out” process was based. The selected verification 
systems were the systems that best satisfied the evaluation criteria. The next phase was 
the “hands-on” study where the empirical study of the eligible verification system was 
conducted and the third phase was the evaluation of the system and the extrapolation of 
the results to attempt to apply them to real life systems. In the empirical study, a 
simplified version of a complex computer security related problem was constructed to 
illustrate and exercise various problem-solving methods. One security model and one 
FTLS was formed from this sample problem. Evaluation criteria was established so that 
during the evaluation process, the results could be measured against the criteria. The 
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evaluation criteria included the previous criteria used in the “filtering out” process as well 
as additional more specific functional criteria. The selected verification system to be 
evaluated was run against the sample problem and the results were tabulated based on the 
evaluation criteria. The purpose of the evaluation criteria was to attempt to reveal any 
inconsistencies in the chosen verification systems such as the potential ability to prove a 
false statement was true. The empirical study process can be summarized as follows: 

(1) Establish a Security Policy 

(2) Develop Mathematical Model of the Security Policy 

(3) Represent this Security Policy Model in terms of the verification tool 

(4) Develop Formal Top Level Specification (FTLS) 

(5) Represent this FTLS in terms of the verification tool 

(6) Map the FTLS to the Security Policy Model 

(7) Attempt to use the tool to prove that the FTLS implements the policy 

In the third phase or the evaluation phase, conclusions were drawn on how well 
the selected verification systems described the security policy and FTLS. Also, 
information on how much assurance the selected verification systems provided and how 
easy it was to prove that the design satisfied the policy was given at the end of the paper. 
The final process consisted of determining whether the results of the evaluation process 
were applicable to real world systems. 

C. CONCLUSION 

Results of the empirical study should determine the usefulness of the verification 
system for the sample problem. In addition, our work was driven by the need of another 
project HANNAH (High Assurance Network Authenticator), which involves the creation 
of a high assurance trustworthy authentication on a network. HANNAH requires the use 
of a verification system, and therefore relies on the results of the evaluation of the 
verification systems. This paper attempted to extrapolate from the results a conclusion 
about the usefulness of a verification system for the verification of real world systems. 
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II. CANDIDATE ELIMINATION FOR EVALUATION 


A. INTRODUCTION 

Choosing which verification tools to use and exactly what support is offered from 
eaeh tool is not always clear. Therefore, there is a need to define eriteria so that the tools 
can be evaluated with respect to their various capabilities. This provides a means of 
finding which tool is suitable for a speeific research environment and what needs of a 
particular project the tool satisfies. There is no ideal tool for a researcher in formal 
methods, sinee the tools come in a vast spectrum of properties and qualifications. 

Tools can range from simulators to model-eheekers to deeision proeedures to 
theorem provers as well as various combinations of these. Theorem provers ean be 
eategorized as interaetive provers, automated provers, logical frameworks, and induetive 
provers. Proofs are intended to assert the correctness and provide feedback as well as find 
errors. In this paper, fifteen verification tools have been preliminary evaluated based on 
speeific evaluation criteria ranging from the “age” of the tool to whether the tool supports 
multiple levels of abstraction. These tools were ehosen as eandidates for this evaluation 
study beeause of the large amount of information available relating to the tools, the tools’ 
differing qualities, and our specific interests in some of the tools. Here is the list of the 
evaluated tools. Next to eaeh tool are the tool’s homepage and a webpage relating to 
information about that tool: 

• ACL2 (A Computational Logie for Applicative Common Lisp)[Moo03] 
www.cs.utexas.edu/users/moore/publioations/km97.ps.Z 

• AutoFOCUS [Tum03] 
www.doos.uu.se/ftrtft96/program.txt 

• Coq [Inr03] 

www-sop.inria.fr/oasis/personnel/ Simao.Desousa/appsemOl .ppt 

• Elf/Twelf[Pfe03] 
www.cs.omu.edu/~rwh/theses/schuermann.pdf 

• HOL (Higher Order Logic)[Iyo03] 
http://citeseer.nj.neo.oom/hougaard94oomputability.html 

• IMPS (An Interactive Mathematical Proof System)[Far03] 


7 



http://imps.mcmaster.ca/doc/imps-overview.pdf 

• Isabelle [Pau03] 

http://www.cl.cam.ac.uk/users/lcp/papers/protocols.html 

• Nuprl [Cor03] 

citeseer.nj.nec.com/constable86implementing.html 

• Otter [Arg03] 

www.cityauditorphilwood.com/warren/sectionfl.html 

• PVS (Prototype Verification System)[Sri03] 
http://www-2.cs.cmu.edu/~svc/papers/view-publications-dk02.html 

• Spec Ware [Kes03] 

http://www.specware. 0 rg/documentation/ 4 .O/tutorial/SpecwareTutorial. 

html 

• SteP (Stanford Temporal Prover)[Sta03] 
http://www-step.stanford.edu/papers/railroad.html 

• TAME (Timed Automata Modeling Environment) [ArcOl] 
chacs.nrl.navy.mil/pubhcations/CHACS/2001/index2001.html 

• TPS (Theorem Proving System)[And03] 
gtps.math.cmu.edu/hug93.ps 

• Vienna (Vienna Development Method) [Ibm03] 
www.sei.cmu.edu/publications/documents/ 88.reports/88.tr.026.html 

• Z/Eves [Ora03] 

www.comp.nus.edu.sg/~dongjs/papers/icfem02dsw.pdf 

B. EVALUATION CRITERIA 

1. Age 

The “age” of a tool can indicate the amount of available documentation of the tool 
regarding improvements, strengths, weaknesses, purposes, and other information relating 
to the overall value of the tool. Tools developed for trusted computing efforts may have 
become obsolete and not been used in a long period of time. A tool can be currently 
supported and employed, yet be relatively new which leads to concerns involving its 
acceptability, usability, and proficiency. The more data collected from the research of a 
verification tool, the more questions that can be answered about that tool. However, even 
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though a tool might be older, it may not be maintained currently, and this could lead to a 
problem. Therefore, the “ideal” tool should be mature as well as be currently maintained 
and supported. From the list of fifteen tools, the ones that have only been developed 
within the last seven years are AutoFOCUS, Coq, Elf/Twelf, and TAME. However, out 
of the complete list of tools, all are being used in some kind of research environment 
currently at either a university (e.g Stanford), laboratory (e.g Carnegie Mellon 
University), or a company (e.g ORA Canada). ACE2, Coq, Z/Eves, Isabelle, PVS, and 
Nuprl all have current versions released in 2002. [Appendix A]The developers who are 
currently supporting each tool can be found in Appendix E. 

2, Purpose 

A tool’s purpose plays a major role in determining how effective it will be when 
used for a particular project. The key qualifications of the tool should be its ability to 
ensure that the system satisfies some set of security properties as well as being able to 
express software properties that are of our interest. If a tool is used exclusively for the 
purpose of satisfying a particular mathematical concern, then its usefulness is 
questionable. ACE2, PVS, Z/Eves are all general purpose theorem proving tools that can 
be employed in almost any environment from small software projects to industrial-size 
verification projects. HOE has a wide variety of uses from formalizing pure mathematics 
to verification of industrial software. The Vienna Development Method (VDM) supports 
the top-down development of software systems and STeP is a tool for the computer aided 
formal verification of reactive systems. ACE2, PVS, Nuprl, Coq, and Isabelle all have the 
ability to tackle real-world problems primarily due to the improved capabilities of 
interactive systems. These systems are used for purposes other than verification. IMPS 
provides organizational and computational support for the traditional techniques of 
mathematical reasoning. TPS has facilities for searching for expansion proofs and 
translating them into natural deduction proofs as well as constructing and translating 
natural deduction proofs. However, its usage in real-world problems and describing 
properties of software has not been documented. Otter’s main application is in abstract 
algebra and formal logic and has been used to answer questions in the areas of finite 
semigroups. However, it also deals more with mathematics and can be difficult to use to 
illustrate the properties of software. [Appendix B] 
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3, Implementation Language 

A tool whose implementation language can be run on many systems becomes a 
more usable and effective tool, due to its portable nature. Therefore, if the tool’s 
implementation language falls in the category of the more “popular” languages (e.g. ML, 
Common Lisp, Java, or C), then the likelihood of it being able to run on a user’s system 
is higher. This reduces the amount of effort that includes time, money, and research to 
find an appropriate environment for the tool. All fifteen tools satisfy this quality, since 
each tool’s implementation language is a “popular” language. [Appendix C] 

4, Resource Requirements 

A tool should be able to run on a specific platform that is currently available at a 
user’s work environment. Otherwise, the cost and time to implement a suitable system 
architecture for the tool increases significantly. Therefore, the tool should be able to run 
on the more familiar operating systems (e.g. Windows and Unix). It is also advantageous 
if the tool can be run on different platforms. ACL2, Otter, Isabelle, IMPS, Coq, TPS, 
AutoFOCUS, Vienna, and HOL can all be run on Unix. TPS, PVS, Z/Eves, Coq, ACL2, 
and SteP can run on Linux. Coq, Z/Eves, and HOL also run on Windows machines and 
SteP, PVS, and Z/Eves also run on Solaris. Nuprl can run in any Common Eisp with 
CEX. Therefore, all the tools run on common platforms, and some can even be run on 
more that two different operating systems. [Appendix D] 

5, User Friendly 

The amount of effort and control that is required by the user to achieve a result 
can determine if a tool is “user-friendly”. The degree of automation can affect the level of 
difficulty of using a verification tool. Eully automatic tools may only need a “push of 
button” and the user just has to wait for the answer. However, these tools are limited in 
what they can verify. In addition, users still have to set prover parameters and generate 
prover commands to pilot the theorem prover. Otter is fully automatic and has more than 
a hundred Boolean and numeric parameters. Eor the prover to perform well, these 
parameters have to be set up correctly, which increases the user’s time and energy spent 
on operating the tool. Interactive theorem provers (a.k.a. “proof checkers”) are driven by 
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the human user, and therefore eompleting the proof is slower and requires more effort by 
the user. However, interaetive provers ean aehieve parts of a proof by itself, and the user 
ean receive assistance from people with expertise in using interactive theorem provers. 
The key qualification that a “user friendly” tool possesses is the ability to use it without 
having to know the language or mechanics of the tool in depth or training to become 
fluent. The beginner should only need to know a basic knowledge of the tool and a small 
repertoire of commands. TPS and SteP can be both proved automatically or interactively, 
however TPS is quite primitive in automatic mode. ACL2 is a semi-automatic inductive 
prover where the user’s responsibility is to understand the mathematical logic, be able to 
construct a proof interactively, and have the mathematical insight of why the model has a 
desired property [Define inductive prover]. Coq, Z/Eves, Nuprl, PVS, IMPS, and HOT 
are all interactive theorem provers. Z/Eves can automatically perform large proof steps, 
yet those steps can by finely directed by the user. With Nuprl, it is impossible to develop 
an incorrect proof and users can write proof generating programs. PVS is much quicker 
than HOE, and HOE users have to first learn some ME before they can effectively use the 
tool. TAME, an interface to PVS, provides a way for users to create proofs using 
“natural” or automatic proof steps, without having to learn the details of the PVS proof 
steps. Also, TAME provides better user feedback in comparison to PVS. Eastly, the 
descriptive language of Vienna is relatively difficult to learn when trying to employ the 
tool, and Elf/Twelf is not suited for the interactive development of theories. When 
deciding which tool to use based on whether the tool is “user friendly”, the ultimate 
choice is dependent on the task at hand. The user may want fine control of the prover to 
investigate proof strategies or proof failings. On the other hand, the task may require 
beginners to use the tool right away, and therefore a tool that requires the least amount of 
knowledge to use it is needed. Therefore, the significance of how “user friendly” a tool 
basically depends on the needs of the user. [Appendix E] 

6, User Interface 

As a supplement to Section 5, the user interface is a more specific attribute that 
helps to categorize the tool by ease of use. A “point and click” graphical user interface is 
much simpler to use than an interface that requires the user to remember 1000 different 
commands. Z/Eves and AutoEOCUS use a graphical interface and TAME also provides a 
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friendly user interfaee. Nuprl, SteP, and Otter use X-Windows, ACL2, Elf/Twelf, PVS, 
IMPS, and HOL use Emacs, and Isabelle uses Ml as their user interface. Coq, however, 
does not use any special interface such as Emacs and has a standard teletype-like shell 
window. [Appendix E] 

7. User Presentation Language 

This section is also a supplement to Section 5. The user presentation language is 
an important attribute of a verification tool and is entirely dependent on the user’s 
preferences, background, and needs. If a user is not familiar with the tool’s presentation 
language, then problems can emerge. The user may have to spend an indefinite amount of 
time to become knowledgeable about the language and the likelihood of mistakes maybe 
higher due to inexperience. It is best if the tool’s interface language is one that the user is 
comfortable with and competent at using. We have not explored the information 
regarding this specific criteria yet, therefore the various tools’ presentation languages will 
be presented in Phase 2. [Appendix G] 

8, Consistency of Specifications 

Verification tools may be used to find errors and inconsistencies and can 
determine the level of confidence of the correctness of a system. However, the tools 
themselves should first be shown to be correct, otherwise what the tool outputs may not 
be trusted. Any inconsistencies in the underlying logic of the verification systems such 
as the potential ability to prove a false statement is true can be detrimental. Eogic that is 
more familiar to users leaves less room for unexpected inconsistency problems. A 
specification is a list of properties that a user expects from a program. When a 
specification includes axioms, the tool should allow new axioms to be added while 
maintaining consistency with the original set. Managing inconsistent specifications 
includes activities such as consistency checking, reasoning, and analysis. A consistency 
checker can expose missing cases, unwanted non-determinism, and other application- 
independent errors. Checking a specification for unwanted nondeterminism and missing 
cases can be computationally expensive and complex otherwise. ACE2, Z/Eves, Nuprl, 
PVS, TAME, Isabelle, and HOE all have some form of consistency checking. Whether 
Coq and Elf/Twelf support consistency of specifications is unclear. More research will be 

conducted due to inadequate information regarding consistency of specifications for the 
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remaining verification tools. However due to limited documentation, conclusions may 
still not be apparent in Phase 2. [Appendix H] 

9, Executable Specifications 

When a specification is executable, a ‘feel’ for the system can be gained. 
Executable specification allows one to demonstrate the behavior of a software system 
before it is actually implemented. Therefore, specifications are constructive, since they 
not only demand the existence of a solution, they actually construct it. Through 
executable specifications, a user can modify and test specifications to achieve some 
expected result. Each specific property can produce several examples that uphold this 
property, and the user can then instantiate theorems via the generalization of these 
examples. ACE2, Coq, Nuprl, Vienna, and HOE all support executable specifications. 
Information on whether the remaining verification tools also possess this attribute will be 
presented in Phase 2. [Appendix I] 

10. Multiple Levels of Abstraction 

Eormal Specification and Verification Tools can be used to achieve a more secure 
system and to provide higher assurance that the system meets the requirements. Several 
steps are followed during the assurance process to reveal any unspecified functionality 
and to create verifiable protection. The initial steps involve developing a security policy 
and a top level specification of the system. Security policies are created to cover all 
aspects of protection of organizational assets. Some of these policies are then represented 
in a Security Policy Model. This model is represented mathematically using precise 
mathematical logic or a specification language that has formal well-defined semantics to 
specify the system. A verification tool may be used to represent the mathematical model 
of the security policy. A formal top level specification (PTES) is created using notations 
derived from formal logic to describe assumptions about the world in which a system will 
operate, requirements that the system will have, and a design to meet those requirements. 
The PTES is also represented by a verification tool. The PTES and the Security Policy 
Model are at different levels of abstraction. Therefore, the verification tool should 
support multiple levels of abstraction so that one can prove that the top level specification 
of the system satisfies the security model. ACE2, PVS, and HOE support multiple levels 
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of abstraction. Phase 2 will determine whether the other verifieation tools satisfy this 
property or will remain questionable due to limited doeumentation. [Appendix J] 

11. Expressiveness 

The degree of expressiveness of a verifieation tool ean determine its usefulness 
when applied to more eomplex and difficult problems. A tool’s expressiveness ean be 
dependent on the logie it uses as well as its unique additional features. Logic, a formalism 
for representing specifieations, can be propositional, first order predieate, higher order, 
temporal, etc. Higher order logic can express the more eomplieated properties in 
eomparison to first order logie. However, one should primarily address whether the tool 
has the ability to suffieiently express properties of software systems, rather then its 
underlying logic. ACL2, Z/Eves, and Otter ean only be expressed with first order logie. 
Coq, Nuprl, PVS, Isabelle, IMPS, TPS, TAME, and HOE are based on higher order logie. 
Sinee ACE2 is programmed in the same logic it supports, this ensures that the logie is a 
praetieal means of building large formal systems. Coq is an extension of the Caleulus of 
Constructions with inductive types and is well adapted to inductive reasoning. Elf/Twelf 
is a logieal framework (EE) based on predieative type theory. Z/Eves has unique 
attributes that inelude an expressive formal speeifieation and programming language, 
praetieal automated deduetion support, and mathematieal soundness. One feature of 
Nuprl is that the logie and system take aeeount of the eomputational meaning of 
assertions and proofs. PVS ean introduee axioms freely and Isabelle ean support 
reasoning in several objeet logics. AutoEOCUS is based on simple temporal logie and the 
logie underlying the semanties of Vienna is based on the Eogic of Partial Eunetions. Due 
to the various different attributes of each tool, once again there is no ideal tool, and 
decisions should be based on the needs of the user and the task at hand. [Appendix K] 
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Evaluation Criteria Summary Statement 


Age 

A tool should be old enough and currently 
maintained 

Purpose 

A good tool should be versatile to verify a variety of 
mathematical problems and be able to express software 
properties 

Implementation 

Language 

The more systems a tool’s implementation language 
can run on, the better it is 

Resource Requirements 

The larger number of common operating systems a 
tool can run on, the better it is 

User-friendly 

A good tool should take the guess-work out and 
make its operation simpler and more flexible to the user 

User Interface 

A GUI tool is better than a non-GUI tool 

User Presentation 
Language 

A user should be familiar with a tool’s presentation 
language 

Consistency of 
Specifications 

A good tool should have consistency checking for 
an entire set of tailorable specifications 

Executable 

specifications 

A good tool should have the capability of 
executable specifications, so the user can get a ‘feel” of 

the system 

Multiple Levels of 
Abstraction 

A tool should be able to support multiple levels of 
abstraction to provide verification that the top level 
specification satisfies the security policy 

Semantics 

A tool’s underlying logic and other unique 
functions can play a role in how expressive it is, however 
the main concern should be whether the tool sufficiently 
expresses the properties of software systems 

Table 1. 

Synopsis of Evaluation Criteria 


C. PHASE 2: SELECTED CANDIDATE: PVS 

The amount of available documentation, the number of satisfied evaluation 
criteria, and familiarity with the tool (See Appendices A - L), resulted in PVS being 
selected as the verification system to be evaluated in the empirical study. Due to time 
constraints, some verification systems could not be fully evaluated in the survey by 
specific evaluation criteria such as multiple levels of abstraction, consistency of 
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specifications, executable specifications, and user presentation language. The proper 
methodology for analyzing those tools in the empirical study is as follows: 

• Express the mathematical model of the security policy by the verification 
system 

• Express the formal top level specification by the verification system 

• Illustrate interlevel mapping between the formal top level specification 
and the mathematical model of the security policy 

A large amount of time is needed to learn a verification tool’s specification 
language, its underlying logic, and especially its theorem proving capabilities. To be able 
to evaluate a verification system to see if it supports multiple levels of abstraction, 
consistency of specifications, and executable specifications as well as determining its 
user presentation language requires an ample amount of time. Installation of the 
verification tool, understanding and writing the various specifications, and proving the 
required theorems are just some of the activities that need to be considered before proper 
evaluation can be done. 

D. CONCLUSION 

ACE2 was also considered an eligible candidate for study since it satisfied most 
of the evaluation criteria and also came with sufficient documentation. Due to time 
limitations, the formal security policy model as well as the formal top level specification 
(ETES) could not be expressed in ACL2. However, a background of ACE2 containing 
information about its theorem prover, underlying logic, and special features as well as a 
brief comparison between PVS and ACE2 is provided in this paper. In future research, 
ACE2 will be evaluated following the same methodology introduced in this paper to 
evaluate PVS. A more in depth view of the process of our empirical study of a 
verification tool can be found in Chapter VI, Section E. 
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III. FORMAL SECURITY POLICY MODEL 


A. INTRODUCTION 

Formal methods is a rigorous method of analyzing the trustworthiness of a 
system. This technique is based on the use of models. With mathematical rigor, it can 
establish certain properties about a system. The goal of formal methods in the 
development of secure systems is to show that a security policy is consistent and 
completely enforced by the modeled system. The goal of a security policy is to “protect 
the confidentiality, integrity, and availability of the system against attacks by malicious 
users and mistakes made by innocent users”[Sec98]. In order to provide an adequate level 
of protection, a computer system has to enforce an appropriate set of policies and to 
enforce them correctly. The security model is a precise and unambiguous statement of a 
system’s security policy. It is an obvious representation of the policy. Some important 
security models are The Bell and LaPadula model [Bel73], a confidentiality model and 
the Biba model [Bib77], an integrity model, both of which are lattice models, 
characterized by systems whose labels can be arranged in a lattice dominance hierarchy. 

The formal security policy model is a high level model of the Reference Monitor 
abstract reference and authorization functions. It is a mathematically precise statement of 
a security policy. The formal model enumerates operations that can be invoked to 
observe or modify that state. Also, it must be specific about critical technical elements 
such as what preconditions must be true for the operation to begin, what post-conditions 
will be true when the operation ends, and exactly what changes of the identified state will 
occur. The formal model needs to be abstract where the system state is divided into 
explicit and implicit parts. The specification describes pre- and post condition, and 
effects, only on explicit state. Therefore, non-determinism is permitted (satisfying pre¬ 
conditions is not a guarantee of execution). The formal model is kept as simple as 
possible, and detail is added only when it is required to prove that the implementation 
satisfies the initially stated requirements and security properties. As a consequence, the 
specification may contain non-deterministic transitions; one purpose of refinement is to 
resolve non-determinism in a way that is consistent with the initial properties and 


17 



requirements [Sec96]. The formal model is of a system interface, in other words it is an 
abstract model of something real and it is written in a formal specification language. 
[Irv03] 

The formal security policy model consists of two parts: 

• A general model of a system (system as a state plus a set of operations) 

• A definition of a secure system - Each formidable clause in the security 
policy is turned into a predicate that constrains the system in some way. 
The overall definition of a secure system is one where all the constraints 
are satisfied. 

The model must represent the initial state of a system, the way in which the 
system progresses from one state to another, and a definition of a “secure” state of the 
system. To be acceptable as a basis for a TCB, the model must be supported by a formal 
proof that if the initial state of the system satisfies the definition of a “secure” state and if 
all assumptions required by the model hold, then all future states of the system shall be 
secure. 

B. NON-DISCRETIONARY ACCESS CONTROL 

Non-Discretionary Access Controls are access controls based on rules and 
information associated with the subject and object where the information is called a 
security level and the levels are implemented as Labels. Label-Based policies in which 
objects (fdes, directories, etc.) and users of a computer system have security labels can 
confine malicious activities such as Trojan Horse Attacks. When a system supports 
labeled data and labeled users it can reflect a real picture of what sensitive and non¬ 
sensitive information there is on a system. Liles are labeled with a fixed access class 
value and users can execute at an access class level that is constrained by a user’s 
clearance level. This label comparison is the basis of the access control. Mandatory 
Access Control (MAC) is the most commonly used non-discretionary access control. 
Under MAC, if a subject label and the object label cannot be compared then access is 
denied, however if they are comparable, access is determined based on rules regarding 
the relationship between the labels. [Sul03] 


18 



C. THE BELL AND LAPADULA MODEL 


The Bell and LaPadula model (BLP) [Bell73] has been the most influential model 
of security over the past -'30 years. The policy in the BLP model and some of the 
elements of the model are embedded within the Trusted Computing System Evaluation 
Criteria (TCSEC) also know as the “Orange Book”[Sul03]. The Bell and EaPadula 
model, a confldentiality model, has three main axioms: 

• BEP Axiom 1 

Simple-security property(SS): a subject 5 is allowed to read an object o only z/the 
security label of s dominates the security label of o 

o No read up 

o Applies to all subjects 

• BEP Axiom 2 

^-property: a subject 5 is allowed to write an object o only if the security label of o 
dominates the security label of s 

o No write down 

• BEP Axiom 3 

Discretionary Security Property (ds): A state satifies the “ds” property if for each 
member of the current access set, the specified access mode is included in the 
access matrix entry for the corresponding subject-object pair [Sul03] 

o Allows an individual to extend access to an object to anyone that is 
allowed to observe the document under the SS and the property 

o Can only reduce the set of reachable states 

The security policy that will be used in this paper will be very similar to the Bell 
and EaPadula model. Each subject will be given a fixed security label and each object 
will also be given a fixed security label. 
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D. CONSTRUCTING OUR FORMAL SECURITY POLICY 
MODEL 


1. Security Policy 

• Property 1 (same as BLP Axiom 1) 

Simple-security property(SS): a subjeet 5 is allowed to read an objeet o only z/the 

seeurity label of s dominates the seeurity label of o 

o No read up 

o Applies to all subjects 

• Property 2 

Property 2\ a subjeet 5 is allowed to write an objeet o only z/the seeurity 
label of o is equal to the seeurity label of s (restrieted speeial ease of BLP 
Axiom 2) 

o No write down 

• Property 3 

Property 3 (Tranquility Principle): the statie seeurity level of a subjeet 
may not ehange 

Tranquility restriets the ehanging of seeurity labels of subjeets and objeets. Strong 
tranquility is where seeurity labels of subjeets and objeets never ehange during an 
operation. Weak tranquility is where seeurity labels of subjeets and objeets never ehange 
in sueh a way as to violate the seeurity poliey. Our model assumes strong tranquility. The 
advantage is that the system state always satisfies seeurity requirements, however the 
disadvantage is that the system beeomes less flexible. 

2. The Basic Security Theorem 

When writing a formal model or speeifieation, “the general validation approaeh is 
to state and prove theorems about the model that one intuitively expeets to be 
true”[Irv03]. Ineonsisteneies, unintended funetionality, and mistakes in the speeifieation 
are uneovered when proving the test theorem is true. This theorem is appropriately 
named the Basie Seeurity Theorem or the Fundamental Theorem and takes the form of a 
safety property or invariant. The real value provided by the Basie Seeurity Theorem 
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(BST) is that the security can be demonstrated to be an inductive property where a 
change in state of one object can affect the state of other objects which in turn effects the 
whole system. “The specification process utilized in the BST can prove extremely 
valuable when attempting to map the objects of an information system and the 
vulnerabilities that are associated with these objects” [Kav02]. The BST provides the 
following properties: 

A system is secure iff 

• Its initial state is secure 

• Each action that starts in a secure state results in a secure state 

In our model, a secure state satisfies properties one through three. 

3, Anatomy of our model 

a. Elements 

• Subjects: active entities (users, processes,...) 

• Objects: passive entities (data, files, directories,...) 

• Access Attributes {read, write} 

• Security Levels (Top Secret, Secret, Classified, Unclassified) 

b. Components 

• Current Access set 

• Object hierarchy 

• Access matrix 

• Security Level function - Mapping Subjects and Objects to 
Security Labels 

c. Properties 

• The system should satisfy Property 1, 2, and 3 from above 

d. Rules 

• State transition operators 
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e. 


Theorems and proofs 
Justifications and proof 




o Basic Security Theorem 

E. THE MATHEMATICAL MODEL OF THE SECURITY 
POLICY 

• Eaeh subjeet and object is assigned a seeurity label 

Let slSubjeet be a funetion from subjeets to seeurity labels {slSubject: Subject -> 
SL) and slObjeet be a funetion from objeets to seeurity labels {slObject: Object - 
> SL). In addition, let SL be a set of security labels. The seeurity labels are 
elassified as {Top-Seeret, Seeret, Classified, Unelassified}. Assume that SL is 
totally ordered and finite. 


Subject 

SL 

Si 

TS 

S2 

S 







Si 

C 


Table 2. Subjects to Security Labels 


Object 

SL 

O] 

S 

02 

TS 







Oi 

C 


Tables. Objeets to Seeurity Labels 
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Let there be i subjeets and a speeifie subjeet is represented by Si 

Let there be j objeets and a speeifie object is represented by oj 

Let M be a set of distinct modes of access (rd, wr) between a subject and 
an object 

Let the current access authorizations (CAA) be a function from 

Subject X Object -> M. CAA represents the current access set of the 
system. 

Example of the authorization matrix 

This authorization matrix represents the current access authorizations 
(CAA) of subjects to objects and therefore the constraints on information 
flow. The read privilege is represented by r and the write privilege is 
represented by w. 


Si 

Subject S2 


Si 

Table 4. 

The Mathematical Model of the Security Policy 
o CAA(si, Oj, r) —>slSubject(si) > slObject(oj) 
o CAA(si, Oj, w) —>slSubject(si) = slObject(oj) 


Object 

Oi 02 ■ ■ ■ Oj 


rw 

r 


rw 




r 

rw 



r 



r 


rw 



rw 




rw 

rw 



r 

r 


rw 


rw 


r 



Subjects to Objects 




F. CONCLUSION 


A security policy is a statement of the security we expect the system to enforce. 
The security policy model can represent a security policy or a set of policies. It focuses 
on characteristics of policies by abstracting away detail. Generally, the security policy 
model is stated in a formal language such as mathematics. Mathematical logic 
separates and clarifies important components of the system. Given the complexity of 
modem computer systems, it is no wonder that models of some form or another are used 
in an effort to gain an intimate understanding of their inner workings [Kavanagh]. 
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IV. FORMAL TOP LEVEL SPECIFICATION 


A. INTRODUCTION 

A formal top level speeification (FTLS) is a top level specification that is written 
in a mathematical language to allow theorems showing the correspondence of the system 
specification to its formal requirements to be hypothesized and formally proven. It is also 
a description of the system that shows those system changes that may interact with the 
security properties of the system. The components of a classical FTLS include a 
mechanism for describing the security portions of the system state and the state 
transitions of the system that are security relevant. The goal of the FTLS is to prove that 
if the system starts in a secure state, then it will never enter an insecure state using the 
allowable state transitions. 

The FTLS shows the actions of the system including all the exceptions and should 
characterize inputs, outputs, and effects. There should be a coherent mapping between 
inputs and outputs. Processing takes a set of inputs applies them to the current state and 
results in outputs and effects. The effects are the changes to the internal state. It may be 
the “side effects” of the state changes or error handling. Therefore, the elements of a state 
include the effects that were created from processing. Processing also reports errors that 
occur in the system that are not shown in the effects. Error checking and reporting is 
important since in the normal case, state changes should not be made if there are any 
errors in the system. In addition, these errors such as a subject accessing an object that 
does not exist can lead to a potential covert channel. The FTLS is an abstraction of all the 
processing and the effects. “Writing an FTLS is valuable because many behaviors of the 
system that have an impact on security can easily be overlooked in a less formal 
description. This is particularly true of behaviors that might be considered side effects of 
operations that have some other primary purpose” [Sec96*]. 

When constructing a FTLS, an interface specification for the implementation 
should first be developed. The implementation consists of a number of security-related 
and non-security related entry points. A mapping should then be constructed from the 
interface to the FTLS class. Each security related entry point in the implementation 
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should be mapped to a transform funetion in the FTLS whieh is turn should be mapped to 
a transform function in the model. Therefore, the interface can be characterized in terms 
of transforms. The non -security related entry points should be mapped to some 
“no operation” transform in the FTLS that should be mapped to a “no operation” 
transform in the model. 

A system cannot make changes without inputs, therefore there are inputs 
associated with each entry point. Specifying all the entry point accounts for all the 
activities and state changes that can occur in that system. Therefore, the FTLS can 
completely characterize the implementation system. Since mapping the implementation 
to the formal security policy model can be rather difficult, the FTLS provides an 
abstraction of the properties of the implementation that in turn can be mapped to the 
properties of the formal security policy model(See Figure 2). 

In conclusion, the formal top level specification of the TCB (Trusted Computing 
Base) should accurately describe the TCB in terms of exceptions, error messages, and 
effects. The FTLS should be an accurate description of the TCB interface and describe 
the operations that the TCB provides at its interface and the information that those 
operations return which are dependent on the internal state of the TCB. In other words, 
the FTLS should specify accurately all operations and the effects of those operations on 
all system structures that it might have modified and that are visible to the user. In 
addition it should specify accurately the effects of those operations on all structures 
associated with other subjects that can affect the error messages and return values that 
those subjects will subsequently receive. The FTLS must support three main goals. First, 
it must support a proof that the system design enforces the security policy. Secondly, it 
must provide a basis for a catalogue of all covert storage channels. Lastly, it must provide 
a criterion of correctness for the implementation [Rad87]. 

B. CONSTRUCTION OF THE FORMAL TOP LEVEL 
SPECIFICATION(FTLS) 

The FTLS is a complete description of the behavior of the system at a particular 
level of abstraction. It is complemented by a user interface specification that gives a more 
concrete description of the appearance of the system. Many implementation details of the 
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computer system are not represented in the FTLS. The proeess of developing the FTLS is 
as follows: 

1, Represent the State Elements of the Implementation as State 
Elements of the FTLS 

The security-significant state elements of the implementation of the computer 
system may be viewed abstraetly as proeesses, and memory bloeks, and their 
relationships. In a system, inputs are called requests and outputs are called deeisions. 
The system consists of all sequences (request, decision, state) with some initial state. 
Each process and memory bloek will have a fixed associated seeurity label. In addition, a 
process will be associated with a set of memory bloeks, eaeh with a given aceess mode 
(read or write) for that proeess. Eaeh proeess will be identified through an identification 
number appropriately labeled as ProcessID. Two processes can share the same set of 
memory blocks and a process can be associated with a different set of memory blocks 
and different aecess modes for those memory bloeks at various times(See Eigure 3). 

2, Represent the Entry Points of the Implementation as Transform 
Functions of the FTLS 

With respect to this FTLS and Model, the security-significant entry points of the 
computer system are those for the opening and closing of data objects (e.g., fdes).The 
corresponding FTLS transform functions are adding a memory segment with a specific 
mode to a proeess and deleting a memory segment with a specific mode from a 
prooess(See Figure 3). 

C. CONCLUSION 

The seeurity policy model and the formal top level specification are simple 
models whose primary purpose is to illustrate the inter-level mapping problem. 
Therefore, the level of detail in both these specifieations will be expanded in future 
researeh. For example, information flow is not modeled in our speeifications since we 
assume that it is handled elsewhere. This is the differenee between this model and a non¬ 
interference model. In our specifieations, we model “open/close” of a subjeet accessing 
an object, however we do not model “read/write”. Clearly, there are many aspects of our 
policy that could be implemented in our model, however due to the limited amount of 
time, our main foeus was on demonstrating the inter-level mapping problem. 
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Figure 2. Detailed Mapping of the Multiple Levels 
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V. THE PVS SPECIFICATIONS 


A. INTROUCTION TO PVS 

The Prototype Verifieation System (PVS) can be defined as a verification system 
that provides an interactive specification/verification environment for writing formal 
specifications and verifying formal proofs. This system lets the user interactively guide 
the proof construction and provides powerful theorem-proving capabilities as well as an 
expressive specification language. One of its most special features is the use of various 
decision procedures for different logical domains. 

1. Semantics 

The semantics of PVS consists of classical higher-order logic and includes 
predicate subtypes, dependent typing, and parameterized theories. The basic logic in PVS 
is propositional logic extended with equational logic. Abstract data types such as lists and 
trees can be defined and axioms can be introduced freely. Definitions, which allow for 
conservative extension can be recursive and can include inductively defined predicates 
and recursively -defined abstract data types. Standard PVS types include; 

• numbers 

• tuples 

• arrays 

• records 

• functions 

• sets 

• sequences 

• lists 

• trees 
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2, Typechecking 

Typechecking is another feature offered by PVS that resolves name references, 
introduces user-specified type conversions, and makes sure that the types are consistent 
within the specification. The typechecker will generate proof obligations that may have to 
be proved using the interactive prover, however most can be dismissed automatically. 
These proof obligations allow refined typing to be asserted through subtyping judgments. 
This provides strong checks on consistency and other properties. The type system of PVS 
is undecidable, so typechecking is not completely automated. 

3, Theorem Prover 

PVS’ interactive theorem prover/proof checker consists of numerous proof 
commands that can be placed into individual categories[l]; 

• Annotation 

• Control 

• Structural 

• Propositional 

• Quantifier 

• Equality 

• Using Definitions and lemmas 

• Extensionality 

• Induction 

• Simplification using decision procedures and rewriting 

• Installation and Removal of rewrite rules 

• Making type constraints explicit 

• Model Checking 

• Converting a strategy to a rule 


32 




Execution of a certain command can create subgoals or complete a goal. 
Therefore, the proof checker becomes the manager of the construction of the proof by 
prompting the user to give adequate commands for a certain subgoal. For example, in 
Figure 4, the goal is to prove sec_is_secure which is to prove that for a sequence of 
states, every state in the sequence is secure. By induction, the goal to is split into two 
distinct subgoals where the first is proving the initial state is secure. The second subgoal 
is to prove that if n is not the initial state and by hypothesis the prior state was secure, 
then all reachable states after the nth state are secure. 


seq_is_secure: 


{1} FORALL n: st?(nth(seq, n)) 

Rerunning step: (induct "n") 
Inducting on n on formula 1, 
this yields 2 subgoals: 
seci_is_secure. 1 : 


{1} st?(nth(seq, 0)) 

Rerunning step: (use seq_0_secure) 

Using lemma seq_0_secure, 

This completes the proof of seq_is_secure. 1. 

seq_is_secure.2 : 


{1} FORALL j: st?(nth(seq, j)) IMPLIES st?(nth(seq, j + 1)) 

Rerunning step: (skolem!) 

Skolemizing, 
this simplifies to: 


Figure 4. Proofs of Goals and Subgoals in PVS 


PVS comes with a number of predefined theories (i.e.; proven “goals”) and its 
theorem prover automates most of the low-level proof steps. The prover also consists of a 
powerful collection of inference steps that include Boolean simplification, arithmetic and 
equality decision procedures, and automatic rewriting. 
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IMPtrivsy stemT CC1.1 : 

I--- 

{1} 0 = rem(6)(0) 

Rerunning step: (use "rem zero") 

Using lemma rem zero, 
this simplifies to: 

IMPtrivsystemT CC 1.1 : 

{-1} rem(6)(0)=0 

I--- 

[1] 0=rem(6)(0) 

Rerunning step: (assert) 

Simplifying, rewriting, and recording with decision procedures. 
This completes the proof of IMPtrivsystemTCCl.l. 


Figure 5. Using a Pre-defined Lemma from the PVS Prelude File 

For example, in Figure 5, the goal is to prove that 0mod6 = 0 whieh is written 0 = 
rem(6)(0) in PVS. The use eommand invokes lemmas with instantiation. Therefore, in 
this example, a lemma called “rem_zero” defined as rem_zero: LEMMA rem(b)(0) = 0 
for all positive integers b and found in the modulo_arithmetic pre-defmed theory of PVS 
is used. Since rem(6)(0) = 0 is found true, the assert command which uses decision 
procedures to assert sequent formulas is able to prove the given goal. PVS can prove 
automatically many results through its automation. Therefore, when dealing with more 
complex problems, the user has the ability to concentrate on directing the steps to be 
taken rather than the focusing on other details. 

4. Concerns 

PVS does not support operator-defined theories, proof by contradiction, or 
derived rules. Operator theories are theories with operators that handle equations of 
associativity, commutativity, and identity efficiently. They can be important with respect 
to rewrite techniques. Proof by contradiction is an indirect method of proof where the 
proof assumes that the negation of a formula to be proved holds so that it can derive a 
contradiction. Derived rules are rules that can be used in addition to the basic proof rules. 
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and each application of a derived rule can be replaced with a combination of applications 
of the basic proof rules. Adding derived rules may be necessary for conveniently 
embedding specification languages and their corresponding proof rules in the system, in 
order to provide a theorem proving environment for the original specification languages 
[Zha98]. PVS also lacks structures to support readability and ease of change. Therefore, 
a beginning user of PVS may find it difficult to create adequate and worthy 
specifications. Lastly, type checking is time critical since it is part of the interaction and 
can take up to thirty minutes to type check for large contexts [Kroening]. 

B. UNDERSTANDING THE PVS SPECIFICATIONS 

1. The Formal Semantics of the PVS Specifications 

a. The Simple Type Theory 

i. Introduction 

PVS is a strongly typed specification language. Expressions are 
checked to be well typed under a context that is a partial function that assigns either a 
TYPE, CONSTANT, or VARIABEE. Bool and real are base types that are examples of 
pretypes of the simple type theory. [A -> B] is defined as a function pretype from 
domain pretype A to range pretype B. A type is a pretype that has been typechecked in a 
given context. 

The preterms of the language consist of the constants, variables, 
pairs, projections, applications, and abstractions. Eambda abstractions have the form 
EAMBDA(x: T), where T is a pretype and a is preterm. [Owr99] 

ii. Contexts 

A context is a sequence of declarations, where each declaration is 
either a type declaration s: TYPE, a constant declaration c: T where T is a type, or a 
variable declaration x: VAR T. Preterms and pretypes are typechecked with respect to a 
given context. [Owr99] 

b. Subtypes 

Subtyping is one of the main features of the PVS Specification Eanguage. 
A predicate type in PVS is a function type where the range is the primitive type bool. A 
predicate is a term that has a predicate type. Since the elements of the subtype {x: T | a} 
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satisfy the predicate X(x: T): a, this is called a predicate subtype to distinguish it from 
other forms of subtyping. Type equivalence and type correctness are undecidable. Proof 
obligations are generated during typechecking and those obligations are the only source 
of such undecidability. [Owr99] 

c. Dependent Types 

In dependent typing, the type of one component of a product depends on 
the value of another component, or the type of the range of a function varies according to 
its argument value. An important degree of flexibility and precision is added to the type 
system when using dependent typing. Dependent typing representation can be seen 
below [Owr99]. 

• [i:nat, {j:nat|j^i}] 

• [i; nat, {j:nat | j ^i} -> bool] 

2. Language of PVS Specifications 

A PVS specification consists of a collection of theories. Each theory consists of a 
signature for the type names and constants introduced in the theory, and the axioms, 
definitions, and theorems associated with the signature. 

a. Declarations 

Entities of PVS are introduced by means of declarations that introduce 
types, variables, constants, formulas, judgements, and conversions. Declarations 
introduced in one theory may be referenced in another by means of the IMPORTING 
clause. 

i. Uninterpreted Type Declarations; T; TYPE 
Uninterpreted types support abstraction by providing a means of 

introducing a type with a minimum of assumptions on the type. TYPE+ signifies that the 
entity is nonempty. 

ii. Uninterpreted Subtype Declarations: S: TYPE EROM T 
K; TYPE EROM T has the same meaning as: 

k_pred: [t -> bool] 
k: TYPE = (k_pred) 

iii. Interpreted Type Declarations: T; TYPE = nat 
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Interpreted type deelarations are primarily a means for providing 
names for type expressions. 

iv. Enumeration Type Deelarations; T: TYPE = {a, b, e}; 
Enumeration type declarations are of the form: enumeration: TYPE = {e_l,..., e_n} 
where the e_i are distinct identifiers. 

V. Empty vs. Nonempty Types 

When type checking, the following rules are hold; 

• Constants declared must be of a nonempty type 

• Uninterpreted type or subtype declarations defined by 
TYPE can be empty 

• TYPE+ is used for assuming nonemptiness for 

uninterpreted type declarations. 

• TYPE+ is used for assuming nonemptiness for 

uninterpreted subtype declarations as long as the supertype 
is nonempty. 

The type of an interpreted constant is nonempty, as the definition 
provides a witness and interpreted type declarations defined by TYPE are not assumed to 
be nonempty. An interpreted subtype declaration with a CONTAINING clause is 
considered nonempty. There is no TCC generated since the CONTAINING clause is a 
witness to the type. 

vi. Variable Declarations 

Variable declarations introduce new variables and associate a type 
with them. So that binding expressions and formulas can be succinct, these variable 
declarations provide a name an associated type. 

vii. Constant/Eixed Declarations 

PVS’ underlying logic is higher order and the term constant refers 
to functions and relations as well as the usual constants. 

viii. Eormula Declarations 

Axioms, assumptions, theorems, and obligations are formula 
declarations that are introduced with the keywords AXIOM, ASSUMPTION, 
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THEOREM, AND OBEIGATION respectively. Axioms are not expected to have an 
associated proof and are assumed to be true. 

b. TYPES 

i. Subtypes 

A subtype is any collection of elements of a given type itself forms 
a type. The supertype is the type from which elements are taken. The elements that form 
the subtype are determined by a subtype predicate on the supertype. Much of the 
expressive power of the language comes from the subtypes in PVS, however the cost is 
making typechecking undecidable.[Owr01*] When typechecking is undecidable, this 
leads to proof obligations (TCCs). These proof obligations can be discharged with the 
assistance of the PVS prover. The TCCs provide a debugging mechanism which point 
out flaws in the specification or what can be added for improvement. In the end, the 
TCCs generated provide a helpful tool to potential users when trying to build a 
specification that best represents their model. 

ii. Eunction Types 

Eunction Types come in the form: X: x -> y 

iii. Record Types 

Record types have the form [# ai: ti, ..., an: C #]. 

c. Expressions 

i. Boolean Expressions 

ii. lE-THEN-EESE 

iii. Binding Expressions 

Binding expressions use keywords such as EORALE, EXISTS, or 
EAMBDA and consist of operations, a list of bindings, and an expression. 

iv. Set Expressions 

Sets of elements of type t are represented as predicates in PVS. Eor 
example, functions from t to real. 

V. Record Accessors 

If X is of type [# k: int, 1: nat #], an x component can be accessed 

by x'k or k(r). 

vi. COND Expressions: The following expressions are the 


same. 
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COND 


IF A_1 -> B_1 

A_1 -> B_1 


ELSIF A_2 THEN B_2 

A_2 -> B_2 





ELSEIF A_N-1 THEN B_N-1 

ELSE -> B N 


ELSE B N 

ENDCOND 




d. Theories 

i. Theory Parameters 

Theory parameters can consist of types, subtypes, constants, and 
imported theories. When instantiating a theory within another theory, the specification 
needs to provide actual parameters that substitute for the formats. 
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PVS Language 

Example in Specifications 

Uninterpreted Type Declaration 

State: Subject: TYPE+ 

Uninterpreted Subtype declaration 

FTLSSaec: ProcessID: TYPE+ FROM nat 

Interpreted Type Declaration 

State: Access: TYPE ^ f#u: Subject, f: Object, m: 

Mode #J, Access_State: TYPE = setof[Access] 

Enumeration Type Declaration 

State: Mode: TYPE = {rd. wrj 

Empty vs. Nonempty Types 

FTLSSoec: MemBlock: TYPE+ = f# lb: Memory, 
ub: {x: Memory \x>^ lb}#] CONTAINING (# lb 
:= MAXMEM. ub := MAXMEM #), ProcessID: 
TYPE+ FROM nat 

Variable Declarations 

FTLSSpec: p: var Processes 

Constant Declarations 

State: addit. del: Action, no op: setoffActionl 

Formula Declarations 

FTLSSpec: AdditNotDel: AXIOM NOT addit = 
del 

Subtypes 

FTLSSpec: 

SystemMemBlocks: TYPE+ = {SetofMB 
ValidMemBlocks(sysmb)}CONTAINING (x: 
MemBlock \x = (#lb:^ MAXMEM, ub 

MAXMEM #)} 

Function Types 

State: slSubject: Subject -> Label 

Record Types 

State: Access: TYPE = [#u: Subject, f: Object. 

m: Mode #] 

Boolean Expression 

State: AddnotDel: bool = NOT addit = del 

IF-THEN-ELSE 

FTLSSpec: SecureProcTransformfr: Reauest. Pr: 
Processes): Processes = IF SecureRequest?(r) 
THEN ProcTransformjr, Pr) ELSE Pr END IF 

Binding Expressions 

FTLSSpec: ValidMemBlocksfsmb: 
setof[MemBlock]): bool = FORALL(e, b: 
MemBlock) : member(e, smb) AND member(b, 
smb) => (e'lb > b'ub) OR (b'lb > e'ub) AND 
NOTe=b 

Set Expressions 

FTLSSpec: SetofMB: TYPE+ = 

setof[MemBlock] CONTAINING 

{x: MemBlock \ x = (# lb MAXMEM, ub = 

MAXMEM#)} 

Record Accessors 

FTLSSpec: ValidMemBlocksfsmb: SetofMB): bool 

FORALL (e, b: MemBlock): 

NOT e = b AND memberje, smb) AND member(b, 
smb) => 

(elb > b'ub) OR (b'lb > e'ub) 


Table 5. Examples of the Language of PVS 
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C. ANATOMY OF THE FORMAL SECURITY POLICY MODEL 
SPECIFICATION 

1, Elements 

a. Subjects 

Subject: TYPE+ 

b. Objects 

Object: TYPE+ 

c. Access Attributes {read, write} 

Mode: TYPE+, rd: Mode, wr: Mode 

d. Security Levels (Top Secret, Secret, Classified, Unclassified) 

See specification SLabels 

2. Components 

a. Current Access set 

The current access set defines the access state as a set of triples (subject, 
object, access-attribute) where the “subject” has current “attribute” access to “object”. It 
does not identify all the possible accesses, but only identifies one possible state which is 
the one the system is in currently. In the State specification, an instance of Access_State 
defines a current access set. 

Access: TYPE = [#u: Subject,/: Object, m: Mode #] 

Access_State: TYPE = setof[Access] 

b. Object hierarchy 

This consists of a parent-child relation structure on objects where the 
security level of the parent dominates the security level of the child. This hierarchy will 
not be given importance and therefore will not be represented in our formal security 
policy model. 

c. Security Level function 
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The security level function determines the security levels for subjects and 

objects. 

slSubject: [Subject -> Label] 

slObject: [Object -> Label] 

slSubject and slObject are functions that take a Subject and 
Object(respectively) and return an associated fixed security label of that subject and 
object(respectively). Each subject/object cannot have more than one security label 
associated with it and the security label associations are fixed. 

d. Access matrix 

The access matrix used in this paper is a simple representation of 
subject/object accesses. As seen in Table 4, one column is for each object (including 
subjects that are objects), and one row is for each subject. Each cell contains sets of 
access attributes. The cell of the ith row and the jth column contains the access attributes 
of the ith subject in the matrix (Sj) to the jth object in the matrix, (Oj). The current access 
set is a subset of the access matrix. 

Secure Access (a: Access): bool = 

COND a'm = rd-> slSubJect(a'u) >= slObject (a'f), 
a'm = wr -> slSubject(a'u) = slObject(a'f) 

ENDCOND 

SecState(st: Access_State): bool = 

FORALL (a: Access): member(a, st) -> SecureAccess(a) 

Access jnatrix: {a: Access \ SecureAccess(a) } 

SecurcAccess is a boolean function that defines whether a given access 
relation is secure. Therefore, it checks to make sure that read and write modes are only 
assigned when the properties of our security policy are satisfied. This is achieved through 
a security label comparison between the subject and object {slSubject and slObject 
respectively). Access jnatrix is the set of accesses that are secure and represents the 
super matrix. Since it is not needed in the specification, it has not been included in our 
State specification. AccessjState and Sec_State are subsets of Access_Matrix. SecState 
and SecurcAccess together represent the security policy. 
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3. Properties 

The system should satisfy Property 1, 2, and 3 from above 

4, Rules 

a. State transition operators 

• Altering current access 

o Get access (add to the current access set) 
o Release access (remove from the current access set) 

Transform(e: Transformlnstance, st: Access_State): Access_State = 

COND e'ac = addit AND SecureAccess(e'a) -> add(e'a, st), 
e'ac = del AND st(e'a) -> remove(e'a, st), 
member(e'ac, no op) -> st, 

ELSE -> st 
ENDCOND 

In Transform, when adding an access to current access set, the access is 
first checked to be secure, and then is added to the set of current accesses. When 
removing an access from the current access set, the access first must be in the set of all 
allowed accesses, and is then removed from that state. Otherwise, if the action of 
altering current access is neither adding to or removing from the current access set, then 
the access state(set of all accesses) remains the same. A transform function takes a 
current access set {Access_State) and a TransformInstance{spQciiymg the transformation 
operation and the access involved) and returns a new current access set. 

D. CONSTRUCTION OF THE FORMAL TOP LEVEL 
SPECIFICATION IN PVS 

1. Anatomy of our model 
a. Elements 

i. Memory Blocks 

Memory is a nonempty set of natural numbers that is bounded by 
some constant natural number represented as MAXMEM. A memory block is a nonempty 
entity represented as MemBlock, a record whose elements consist of the lower and upper 
bound values(located in memory) of the memory block. System memory blocks are 
represented as a set of valid memory blocks(non-overlappmg memory blocks). System 
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memory is then defined as a fixed set of system memory bloeks. MemBlockInstance is a 
reeord whose elements consist of a memory block located in system memory and its 
associated access privilege. 

MAXMEM: nat 

Memory: TYPE+ = {mem: nat \ mem <= MAXMEM} 
CONTAINING MAXMEM 

MemBlock: TYPE+ = [# lb: Memory, ub: (x: Memory \ x >= lb} 
#] CONTAINING (# lb := MAXMEM, ub := MAXMEM #) 

SetoJMB: TYPE+ = setof[MemBlock] CONTAINING 

{x: MemBlock \x = (# lb := MAXMEM, ub := MAXMEM #)} 

ValidMemBlocks(smb: SetofMB) bool = FORALL (e, b: 
MemBlock): 

NOTe = b AND member(e, smb) AND member(b, smb) => (e'lb > 
b 'ub) OR (b 'lb > e 'ub) 

SystemMemB locks: TYPE+ = (sysmb: SetofMB \ 
ValidMemBlocks(sysmb)}CONTAINING (x: MemBlock \ x = (# lb 
: = MAXMEM, ub : = MAXMEM #)} 

SysMem: SystemMemB locks 

MemBlockInstance: TYPE = [# mb : (x: MemBlock \ member(x, 
SysMem)}, m: Mode #J 

ii. Processes (Identified through a Process Identification 

Number) 

ProcessID is an element from the nonempty set of natural numbers. 
A process is associated with a set of memory blocks each with a given mode, as well as a 
process identification number. Therefore, a process is represented as an entity that takes 
a ProcessID number and returns a set of memory blocks associated with that process 
identification number. It is not a function since one process can have different sets of 
memory blocks associated with it at various times. 


ProcessID: TYPE+ FROM nat 

ProcessMB: TYPE = setof[MemBlockInstance] 

Processes: TYPE = [ProcessID -> ProcessMB] 
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iii. Access Attributes {read, write} 

Mode: TYPE+ 

rd: Mo de 
wr: Mode 

iv. Security Levels (Top Secret, Secret, Classified, 

Unclassified) 

Refer to the Slabels specifieation 

b. Components 

i. Mapping to the Current Access Set 

The current aeeess set in the formal security policy model was an 
instanee of Access State. Process State in the FTLSSpec, our specification representing 
the FTLS, provides a direct mapping from the FTLS to the current access set. It defines a 
function that takes a variable of type Processes and returns an Access State where the 
elements of the FTLS can be mapped to elements of the Aecess State. 
slMemBlock: [MemBlock-> Label] 

slPr: [ProcessID -> Label] 

p: VAR processes 

Process_State(p): Access_State = (a: Access \ EXISTS (mbi: 
MemBlockInstance, PID: ProcessID): a'u = PID AND af= 
mbi'mb AND a'm = mbi'm AND member(mbi, p(PID))} 

ii. Mapping to the Access matrix and the Security Policy 

The comparison of security labels generated through the functions 
slPr and slMemBlock of a process and a memory bloek determine read and write 
privileges as stated in SecProcess. This Boolean function states that if all the memory 
blocks associated with a specific process satisfy the security requirements of the poliey, 
then that proeess is seeure. SecProcesses states that if all processes are secure, then the 
eurrent state is secure. This could be represented as a matrix of memory bloeks to 
ProcessID'?, where the cells contain the aeeess privileges. 
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SecProcess(p: Processes, pid: ProcessID): bool = FORALL (mbi: 
MemBlockInstance \ member (mbi, p(pid))): 

COND mbPm = rd -> slPr(pid) >= slMemBlock(mbPmb), 
mbPm = wr -> slPr(pid) = slMemBlock(mbi'mb) 

ENDCOND 

SecProcesses(pr: Processes): bool = 

FORALL (pid: ProcessID): SecProcess(pr, pid) 

iii. Level function 
slMemBlock: [MemBlock -> Label] 
slPr: [ProcessID -> Label] 

slMemBlock and slPr are two functions that determine the security 
labels of memory blocks and processes respectively, 
c. Properties 

• A process has read access to a memory block only if its security 
label is greater than or equal to the security label of the memory 
block 

• A process has write access to a memory block only if its security 
label is equal to the security label of the memory block 


SecProcess(p: Processes, pid: ProcessID): bool = FORALL (mbi: 
MemBlockInstance \ member(mbi, p(pid))): 

COND mbPm = rd -> slPr(pid) >= slMemBlock(mbi'mb), 
mbPm = wr -> slPr(pid) = slMemBlock(mbFmb) 

ENDCOND 
d. Rules 

• State transition operators 

o Altering process table 

■ Add memory block to a process 

■ Remove a memory block from a process 
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If a request’s action is adding a memory block, then add that request’s 
memory block to the request’s process. However, if a request’s action is deleting a 
memory block, then remove that request’s memory block from the request’s process. 

ProcTransform(r: Request, Pr: Processes): Processes = 

COND ac(r) = addit AND SecureRequest?(r) -> 

LAMBDA (x: ProcessID): 

IF NOT X = rp THENPr(x) ELSE add(rmbi, Pr(x)) ENDIF, 
r'ac = del -> 

LAMBDA (x: ProcessID): 

IF NOT X = rp THEN Pr(x) ELSE remove(rmbi, Pr(x)) ENDIF, 
ELSE -> Pr 
ENDCOND 

SecureRequest?(r: Request): bool = 

COND r'ac = addit -> 

((r'mbfm = rdAND slPr(r'p) >= slMemBlock(r'mbfmb)) OR 
(r'mbi'm = wr AND slPr(r'p) = slMemBlock(r'mbfmb))), 

ELSE -> TRUE 
ENDCOND 

E. IMPORTANT NOTES 

1. Sec theory provides the Basic Security Theorem 

The theorem that gets proven at the model level is secjransform. This theorem’s 
overall meaning is that if that if the initial state of the system is secure, then it will never 
enter a non-secure state given the operations (transforms) as defined. The model must 
represent the initial state of a system, the way in which the system progresses from one 
state to another, and a definition of a “secure” state of the system. Secjheory is an 
abstract representation of the Basic Security Theorem. By mapping State and FTLSSpec 
to Secjheory, this verifies that both these specifications satisfy the Basic Security 
Theorem properties given their different defined states. 

2. Prelude File of PVS 

Specifications for many foundational and standard theories are preloaded into 
PVS as prelude theories and are always available and do not need to be explicitly 
imported. In our specifications we use the function add(x, a), remove(x, a), member(x, 
a), and setof(x) which are already defined functions in the sets and definedJypes theory. 

The functions are defined as follows from the prelude: 
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• add(x, a): (nonempty?) = {y| x=y OR member(y, a)} 

• remove(x, a): set = {y| x/= y AND member(y, a)} , /= represents not 
equals 

• member(x, a): bool = a(x) 

• setof: TYPE = [t -> bool] where set; TYPE = setof[t] 

3, Disjointness in our Specifications 

In the State speeifieation, the disjointness of memory bloeks and their read/write 
eonstraints is implied, however in the FTLSSpec it beeomes explieit. 

4, Bus Error 

A few times during the eonstruetion of our speeifieations, we would reeeive a 
message stated “error signal bus” whieh did not allow us to work with our speeifieations. 
To fix this problem, we had to delete all the files in the direetory we were using exeept 
for the speeifieation files. Sinee the proof files were removed, we had to perform all the 
proofs again. Sinee our speeifieations were kept simple, the proof eonstruetion was not 
too time eonsuming. However, in eases of larger applieations, this ean be great problem 
espeeially under time eonstraints. 

F. INTER-LEVEL MAPPING OF THE FTLS AND SECURITY 

POLICY MODEL USING PVS 

1. The Importing Function 

When using the IMPORTING elause, the aetual parameters provided are known as 
a theory instance. An IMPORTING elause forms a relation between the theory 
eontaining the IMPORTING and the theory refereneed. If the entities are visible in the 
IMPORTING elause at some point in the theory, then they are visible to every deelaration 
following. The IMPORTING elause ean be used to map one speeifieation to another 
speeifieation [OwrOl]. The State theory is imported into the ETES speeifieation using 
the IMPORTING elause as follows (See Eigure 6): 

State 

State [Subject: TYPE+, Object: TYPE+, (IMPORTING SLabels) slSubject: 

[Subject -> Label], slObject: [Object -> Label], Action: TYPE+, addit: Action, 

del: Action, noop: setof [Action], Mode: TYPE+, rd: Mode, wr: Mode]: 

THEORY 
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FTLSSpec 

IMPORTING State[ProcessID, MemBlock, slPr, slMemBlock, Action, addit, del, 

no_ops. Mode, rd, wrj 

2. Correspondence between State Elements of the FTLS and State 
Elements of the Formal Security Policy Model 

A ProcessID that identities a proeess in the FTLS beeomes a Subject in the 
seeurity poliey model. A memory bloek represented as MemBlock in the FTLS beeomes 
an Object in the seeurity poliey model. As stated in Chapter V, Seetion D, Process State 
in the FTLS eorresponds to the eurrent aeeess set of the formal seeurity poliey model. 
The seeurity level funetions and SecProcesses of the FTLS eorrespond to the set of all 
allowed aeeesses in the State speeifieation, 

3, Correspondence between Transform Functions of FTLS and 

Transform Functions of the Formal Security Policy Model 

Addition of a memory bloek to a proeess {addit) and a removal of a memory 
bloek from a proeess (del) in the FTLS, beeomes addit and del respeetively in the 
seeurity poliey model. The aetion addit in the seeurity poliey model is the addition of an 
aeeess to the eurrent aeeess set, and del is the removal of an aeeess from the eurrent 
aeeess set. ProcTransform is the funetion that adds or removes memory bloeks from a 
proeess and therefore behaves similarly to Transform in the State speeifieation. 

4, Code Correspondence 

When implementing a seeurity kernel, it is essential to keep the number of lines of 
eode to a minimum. This offers verifiable proteetion and allows the kernel to be analyzed 
more effieiently. A minimized eomputer system is a system that only implements the 
seeurity-related features or requirements of the poliey. Therefore, by limiting the amount 
of eode and mapping the implementation to the FTLS to the formal seeurity poliey 
model, a proof of eorrespondenee from the eode to the poliey ean be developed. 
Minimized systems provide mueh higher eonfidenee against subversion. By having a 
proof of eorrespondenee, untended funetionality and bugs ean be reeognized and fixed in 
the implementation. 

5. Functional Languages 
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When a functional specification is formal, the proof of correspondence shall also 
be formal [Com03]. A functional style formal language’s only representation for an 
operation is a function and there are only expressions and not statements. A functional 
language is useful when writing specifications of models since it has a considerable body 
of theory for automatically reasoning about functionally-expressed algorithms [Irv03]. 
Also, the combination of a functional programming language and theorem provers is 
much more natural than the combination of sequential programming languages and 
theorem provers. Thus, there are theorem provers that accept functional programming 
languages as input [Kro02]. Future research will be conducted to explain or “interpret” 
as to the approach for using a “functional” language for state machine modeling. 
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Figure 6. Inter-level Mapping 
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VI. CONCLUSIONS 


PVS can be used to speeify and validate system requirements, verify that an 
implementation meets the requirements and then help to refine the design in an effort to 
improve system performance. A specification is formed by eombining theories 
describing various components and properties. Each theory is partitioned into 
assumptions, definitions, axioms, and theorems. Benefits of formal speeifieations are that 
they provide a higher level of rigor which enables a better understanding of the problem, 
defects are uncovered that would likely go unnoticed with traditional specification 
methods, identify defeets earlier in the life cyele. Formal specifications enable formal 
proofs that can establish fundamental system properties as invariants. They encourage an 
abstract view of a system that focuses on what a proposed system should accomplish as 
opposed to how to aceomplish it. 

Verification can be achieved by identifying correctness conditions and using PVS 
to prove those correetness conditions. PVS has three features that allow it to deteet 
deviations from these correctness eonditions[Fre02]. 

• It is based on a typed higher-order logic 

• It supports specification using a form of conservative extension 

• The theorem prover provides a powerful, extensible system for verifying 
obligations 

The process of adding definitions to an existing theory is called extension and is a 
common mechanism for writing specifications. A theory is a conservative extension of 
another if the extension adds axioms that only define properties over new operations. 
Therefore, if a consistent theory is extended in a conservative manner, the resulting 
theory is guaranteed to be consistent [Fre02]. In our speeifieations, we did not extend any 
existing theories, however this feature is of great importance when trying to ensure 
eonsistency of specifications. 

Our methodology eonsisted of construeting speeifieations representing the formal 
security policy model and the formal top level speeification, mapping the FTFS to the 
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formal security policy model, and proving that the FTLS maps to the formal security 
policy model. The main purpose of developing these specifications was to demonstrate 
that PVS could support inter-level mapping between the FTLS and the formal security 
policy model. Based on our survey, PVS satisfied the evaluation criteria as seen in Table 
6 that was developed prior to beginning constructing our specifications. The information 
used to establish our results in the survey was taken from available relevant 
documentation about the verification systems. This included the homepages of each of 
the verification tools, formal methods workshop summaries, and papers on projects that 
used verification tools. The list of evaluation criteria below represent criteria that could 
only be analyzed properly by developing our own specifications, providing inter-level 
mapping, and proving the necessary theorems. 

• User Interface 

• Consistency of Specifications 

• User-Friendly 

• User Presentation Language 

• Multiple Levels of Abstraction 

• Expressiveness 

In the next section, how well PVS represented both formal security policy 
model and the FTLS will be analyzed based on the criteria seen above. From there, an 
analysis of how easy it was to prove that the FTLS mapped to the formal security policy 
model will be conducted. The last section will answer the question of what is the next 
step in our empirical study. It introduces ACL2, the next verification tool to be studied, 
gives a brief background and compares ACL2 to PVS, and lastly presents the 
methodology for constructing our specifications (i.e. the functions and theorems 
required). 

A. EVALUATION OF HOW WELL PVS DESCRIBED THE 
FORMAL SECURITY POLICY MODEL AND THE FTLS 

1, Expressiveness and User Presentation Language (Specification 
Language) 
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The specification language of PVS is based on classical, simply typed higher- 
order logic, but the type system has been augmented with subtypes and dependent types. 
Higher order logic provided a straightforward rigorous formalization of any mathematical 
definitions. One appeal of type theory is that the rendering of higher-level mathematical 
notions like functions is rather direct, whereas in set theory it relies on a few layers of 
definition. Our specifications could be written concisely in this high level language. The 
use of higher order logic and the type system allowed us to closely represent the original 
requirements of the policy and an abstract of the implementation. The expressiveness of 
the PVS specification allowed us to express the formal security policy model and the 
FTLS succinctly. The use of PVS’s type system and its underlying logic allowed gave us 
an important degree of flexibility and precision when constructing our specifications. 

a. Predicate Subtypes and TCCs 

Predicate subtypes provide a mechanism for defining new types using 
comprehension. Given any predicate, s?, with domain, D, the predicate subtype(s?) is 
defined as {d: D | s?(d)} [Fre02]. When we used predicate subtypes, it was possible for 
the type checking system of PVS to automatically generate and verify the obligations. 
Predicate subtypes can also be used to check statically for violations such as division by 
zero or out-of-bounds array references, and can also express more sophisticated 
consistency requirements. They are also used to constrain domain/range of operations and 
to define partial functions. PVS does not make any assumptions about the cardinality of 
the sets that interpret its types. Therefore, sets can be empty, finite, or infinite. When a 
predicate subtype is used, the cardinality cannot be checked algorithmically and therefore 
an “existence TCC” is generated. This “existence TCC” is a potent detector of erroneous 
specifications when higher (i.e. function and predicate) types are involved [Rus98]. 
Therefore, in our specifications we added the CONTAINING clause to explicitly state 
that a specific set of elements was nonempty. After adding this clause, the proof 
obligations could be proved automatically. 

b. Dependent Types 

In PVS, function, tuple, and record types may be dependent in the sense 
that some of the type components depend on earlier components. This can be important 

when trying to prove a type check condition which can be seen in Part 2, The Importance 
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of TCCs. In this example, by adding the statement that speeifies that if x is a memory 
bloek element of MemBlockInstance then it is a member of system memory. 

MemBlockInstance: TYPE = [# mb : {x: MemBlock \ member(x, 

SysMem)}, m: Mode #J 

As stated before, dependent typing increases the amount of flexibility and 
increases the precision of the specification. By using dependent typing, expressions can 
be more succinct and easier to understand. 

c. Higher-Order Logic 

Higher-order logic is a logical system, usually a Type Theory, with 
multiple ranges of quantification (usually called types) some of which contain sets or 
functions. Higher-order logic ensures that the specification language applies to the widest 
range of applications. In PVS, predicates and sets can be regarded as essentially 
equivalent. All members of a set are of the same type in higher-order logic. Therefore, 
PVS also allows set notation for predicates. The inclusion of lambda-abstractions allows 
the definition of unnamed functions as is traditional in many languages. Most provers 
support quantifiers, and a few go further. A higher-order syntax allows users to define 
new variable-binding constructs such as least n P (n). Since PVS is based on higher- 
order logic, we were able to write our specifications concisely. We were able to quantify 
over predicates or properties in our specifications. In our specifications we were able to 
use &, OR, =>, FORALL, EXISTS, etc.. 

A specification may be easier to code in higher-order logic, however, the 
proofs can become more complex. In our specifications, since our specifications were 
kept simple, our proofs were not complicated. 

2, Importance of The Type Checking System 

Type Checking Conditions (TCCs) are produced when typechecking a 
specification by checking the semantic constraints, determining the types of expressions, 
and resolving names. Strategies are used to basically expand all definitions of the TCC 
and add semantic information to the internal representation of the parser. Theorem 
proving may be required to establish the type-consistency of a PVS specification and 
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these theorems that need to be proved are called TCCS. They can also be referred to as 
proof obligations. 

The assumptions in the higher level specification become proof obligations 
(TCCs) in the lower level specification. For example, the assumptions in the State 
specification become TCCs in the FTLSSpec specification. When evaluating the 
computer system, the implementation should satisfy the assumptions stated in the FTLS. 
Since implementation details are not known currently, the assumptions are written as 
axioms in the FTLSSpec specification. Type checking conditions point out defects in the 
specification and demonstrate what needs to be added to or deleted from a specification. 
The PVS type checker can be considered as a debugger of the model. 
a. Memory Block in System Memory 

In the initial stages of developing our specification of the FTLS we 
assumed that a memory block that was to be added or deleted from a process was already 
in the system memory. However, proof obligations were generated from the definition of 
ProcTransform. We had to show that when adding or deleting a memory block from a 
process, the set of memory blocks associated with that process after the change would 
still be a subset of system memory. The TCCs generated were: 

% Subtype TCC generated (at line 50, column 46) for add(r'm, Pr(x)) 

% expected type ProcessMB unfinished 

ProcTransform TCCF OBLIGATION FORALL (Pr: Processes, r: 

Request): Fact = addit IMPLIES (FORALL (x: ProcessID): x = Fp 
IMPLIES subset? [MemBlock] (add[MemBlock] (r'm, Pr(x)), SysMem)); 

% Subtype TCC generated (at line 53, column 46) for remove(r'm, Pr(x)) 

% expected type ProcessMB unfinished 

ProcTransform_TCC2: OBLIGATION FORALL (Pr: Processes, r: 

Request): 

Fact = del IMPLIES (FORALL (x: ProcessID): x = rf IMPLIES 
subset?[MemBlock](remove[MemBlock](r'm, Pr(x)), SysMem)); 

Therefore, we had to add that when requesting to add or delete a memory 
block from a process, the memory block itself would already be part of system memory 
to our specification. The following line changes were made: 
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MemBlockInstance: TYPE = [# mb : MemBlock, m: Mode #] 
became 

MemBlockInstance: TYPE = [# mb : {x: MemBlock \ member(x, 
SysMem)}, m: Mode #] 

b. Axiom Additions 

When typechecking the State specification, the following TCCs were 

generated; 

Disjointness TCC generated (at line 46, column 6) for 
% COND a'm = rd -> slSubJect(a'u) >= slObject(a'fi, 

% a'm = wr -> slSubject(a'u) = slObject(a f 
%ENDCOND 
% proved - complete 

SecureAccess TCCl: OBLIGATION FORALL (a: Access): NOT (a'm = 
rdAND a'm = wr); 

% Coverage TCC generated (at line 46, column 6) for 
% COND a'm = rd -> slSubject(a'u) >= slObject(a'fi, 

% a'm = wr -> slSubject(a'u) = slObject(a'fi 
%ENDCOND 
% proved - complete 

SecureAccess_TCC2: OBLIGATION FORALL (a: Access): a'm = rd OR 
a'm = wr; 


% Disjointness TCC generated (at line 54, column 6) for 

% COND e'act = addit AND SecureAccess(e'ac) -> add(e'ac, st), 

% e'act = del AND st(e'ac) -> remove(e'ac, st), 

% member (e'act, no_op) -> st, 

% ELSE -> st 
%ENDCOND 
% proved - complete 
Transform TCCI: OBLIGATION 
FORALL (e: Transformlnstance, st: Access_State): 

NOT ((e'act = addit AND SecureAccess(e'ac)) AND e'act = del AND 
st(e'ac)) 

AND 

NOT ((e'act = addit AND SecureAccess(e'ac)) AND 
member[Action](e'act, no_op)) 

AND NOT ((e'act = del AND st(e'ac)) AND member [Action] (e'act, 
no_op)); 
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Therefore, based on these TCCs, we had to explicitly write some 
assumptions that we had ignored but were of great importance in our model. 

AddDelNotNo_Op: ASSUMPTION NOT member(addit, no_op) AND NOT 

member(del, no_op) 

AddnotDel: ASSUMPTION NOT addit = del 

RdnotWr: ASSUMPTION NOT rd = wr 

AddDelNotNoJDp provides the assumption that the actions addit and del 
are not members of the set of actions that do not have any operations. AddnotDel and 
RdnotWr provide assumptions of disjointness that addit and del are not the same entities 
and read and write are not the same entities respectively. From typechecking the PVS 
theories, we discovered the need for axioms or assumptions that needed to be added to 
the specification. These then lead to properties of the FTLS and hence the 
implementation that we might not have realized if we had not developed the 
specifications. 

PVS, in addition can provide counterexamples to original assumptions and 
thereby suggest extra constraints that need to be formalized [Kro02]. By constructing a 
PVS specification of our model, we have the advantage of using the PVS system to 
analyze the model. This PVS system allows us to ask questions about our model, such as 
the emergent properties of the model. These properties are not explicitly described via 
the axioms of the model itself; rather, they are logical consequences of the axioms 
[PaiOl]. 

The type checker can detect a lot of common specification errors. Since it 
has to be performed again after any change to the theory, it is part of the interaction of 
developing a valid specification. It is the type checking system as well as the 
expressiveness of PVS that allowed us to write concise and suitable specifications for 
representing both the FTLS as well as the formal security policy model. The generation 
of proof obligations provided us with ways to improve the specifications and the 
specification language together with its underlying logic allowed us to write our 
specifications in a flexible and straightforward manner. 
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B. EVALUATION OF HOW EASY IT WAS TO PROVE THAT 
THE FTLS MAPPED TO THE FORMAL SECURITY POLICY 
MODEL 

1, Decision and Inference Strategies 

PVS provides a language for defining high-level inferenee strategies. The typieal 
strategies inelude those for instantiation of quantifiers, repeated skolemization, 
simplifieation, rewriting, and induction. The use of these powerful inference steps allows 
us to define a small number of flexible strategies that suffice for productive proof 
construction [Rus96]. Strong decision procedures have a high degree of automation. For 
example, the "grind" command is like automatic proving, even though this feature works 
only for simple theorems. We still needed to guide it through the proof It plays the role 
of a proof verifier, rather than prover, since it just verifies small proof steps, rather than 
generating the proof on its own. However, when proving TCCs in our specifications, the 
grind command was highly useful. The “grind” command combines various commands 
into one and allowed us to prove the proof obligations quickly. In addition, there were 
times when the strategy for the proof was not apparent, and using the grind command 
either simplified or automatically solved the proof Since our specifications were kept 
simple to illustrate inter-level mapping, the proofs themselves (TCCs and theorems) were 
not difficult to prove. There were some instances however when only by attempting to 
use a specific command could we determine its applicability to solving the proof. 

In a theorem prover, the same axiom can be used in many different ways, 
depending on the context. So a theorem prover is less predictable but more flexible than 
a programming language such as Prolog. When we are searching for contradictions, we 
don’t know in advance how the axioms are to be executed, so we use a theorem 
prover. The “use” command invokes lemmas with instantiation. This allows us to use 
existing lemmas, axioms, theorems, etc from the PVS prelude file or our own defined 
assumptions, axioms, theorems, lemmas, etc. in our specification was used quite 
frequently. Using this command helped us prove many of the proof obligations from our 
specifications. An explanation of the various commands used in our proofs please refer 
to [ShaOl] and the proofs can be seen in Appendix M through O. 

2. Interface 
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a. 


Usability 


The usability of PVS for larger proofs relies on the existence of powerful 
procedures and strategies. Therefore, planning needs to be performed at a more intuitive 
level. A theorem prover should have a set of commands that maps well to the 
corresponding actions and is easy to understand and recall in order to facilitate plan 
formation. With automation taking care of the low level proof, the complexity of the 
built-in procedures means that the outcome of commands cannot be predicted and some 
experimentation is nearly always required [Mer96]. Since PVS’s theorem prover is 
interactive, we essentially had to know the strategy we were going to use in our proof 
before we started. Otherwise, we could end up stuck in our proof construction by going 
down the wrong path. There were help buffers that allowed us to view either one or the 
whole range of possible commands and their correct usage. The interactive prover 
introduced flexibility and we were able to use our own strategies to perform the proofs. 
In other words, PVS supported “user-defined proof strategies”. For example, Czerny and 
Heimdahl in “Using PVS to analyze hierarchical state-based requirements for 
completeness and consistency” define their own strategy called consistent! to prove that 
their specifications are consistent seen in Figure 7. 
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X.X 
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Ground.Level)}) 

X.X 

X The strategy (consistent!}) is conprised of the sequence of cooaands X 
X listed below it. This sequence of cousands skolecizes the goal, X 

X rewrites the above conjunction into its constituent components, and X 

X cospletes the proof. X 

X-X 

Rule? (consistent!}) 

Applying 

(THBi (REifRITE-MSG-OFF) (SXOLEK!) (AOTO-REWRITE-DEFS}) (DO-REWRITE}) 
(REPEAT* (TRY (BODSIHP) (RECORD) (POSTPOKE)))), 

q.E.D. 


Figure 7. User Defined Strategies in PVS 


When eonstructing our proof, after eaeh eommand is entered, the eurrent sequent 
is displayed. Therefore, we were able to get an overview of our progress made at eaeh 
command entered. It is also possible to view the current proof steps as formatted text 
where branching is indicated by indentation which allows the tree structure to be clear. 
This can be seen in the Figure 8 below [Mer96]. 
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Figure 8. Interface of PVS theorem prover 

b. Concerns with the Interface 

Since PVS cannot display standard mathematical symbols, ASCII 
alternatives are used instead. The method of best representing mathematics and logic is 
up to the user. “Pretty-printing” as the name states helps specifications become more 
organized and easier to read. Insertion carriage-returns and indentation are used to make 
the structure of the specification more readily apparent. However, how “pretty” the 
specification becomes is once again a decision made by the user. A problem with 
“pretty-printing” is that it removes comments made in the specification. So, even though 
it helps to structure the specification, it can make the specification harder to understand. 

c. Implementation Language 

When using the help buffers and viewing the theorem prover interface, the 
descriptions and messages are somewhat cryptic unless the user is familiar with the LISP 
programming language. Proof commands are in Lisp syntax, where the first term 
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identifies the eommand, the seeond generally indieates those formulas in the sequent to 
whieh the eommand should be applied, and any required PVS text is enclosed in quotes. 
However, even though not all of us were familiar with the Lisp language, we still were 
able to understand the proof commands and the interface of the theorem prover. 
Therefore, the fact that PVS’s implementation language is Common Lisp may not be a 
hindrance to users who are not familiar with the language. 

3. The Inter-level Mapping Problem 

In the specifications. State is mapped to Secjheory. This mapping supports the 
Basic Security Theorem principles where every state in the sequence of states of the State 
specification is secure. The main goal however is to map the FTLSSpec specification to 
the State specification so that the following occurs (See Figure 9). 
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Sec_Theory(arbitrary 
sequence) 


Assumptions \ 

1. Initial state in a sequence is secure 

2. The next state in a sequence results 
from a transform operation of the 
previous state 

3. If a state is secure, then every state 
that results from a transform operation 
on that state is secure 

Theorem 

Every state in the seauence is secure 


State(defined sequence of 
states) 


Define a state in this specification 
Define a sequence of states 
The assumptions from Secjheory become 
proof obligations(TCCs) in State 
Add the necessary assumptions to prove 
the proof obligations 


FTLSSpec 


1. Map the elements and components of the 
FTLSSpec to the elements and components of 
State and be as concise and precise as possible 

2. The PVS system should automatically construct 
the proper mapping theorems. In other words, the 
TCCs generated should be the mapping theorems 
that provide the inter-level mapping between the 
FTLSSpec and State 

3. The proof that every state of the FTLSSpec is secure 
becomes a trivial proof 



Figure 9. Ideal Inter-level Mapping Construction 
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a. 


Initial Version of the Specifications 


When importing a higher level theory into a lower level theory using the 
IMPORTING clause in our specifications, type-checking conditions (TCCs) are 
generated. These TCCs were to make sure that the assumptions stated in the higher level 
theory are satisfied in the lower level theory. The assumptions of the higher level theory 
become proof obligations in the lower level theory as stated before. However, a problem 
arose in trying to prove those type-checking conditions in an earlier version of our 
specifications. In the earlier version. System was in between the State and FTLSSpec 
levels. The following parameter list of the theory System was used to try to map the 
FTLSSpec theory to the System theory which in turn needed to map to the State theory. 

System[Subject: TYPE+, Object: TYPE+, (IMPORTING SLabels) 
slSubject:[Subject -> Label], slObject: [Object -> Label], Action: 
TYPE+, addit: Action, del: Action, no op: setof[Action], Mode: TYPE+, 
rd: Mode, wr: Mode, (IMPORTING State [Subject, Object, slSubject, 
slObject, Action, addit, del, noop. Mode, rd, wrj) fs: 
sequence[Access_State]]: THEORY 

To be able to prove the TCCs generated from importing the State theory, 
we needed to be able to use the assumptions in the System theory. These assumptions 
were the same as the assumptions of the current State theory (Appendix M). However, 
the problem was that we could not use the assumptions of our System theory since they 
were defined after the IMPORTING clause was introduced. The IMPORTING clause 
functions by only using the information prior to its use. Since PVS did not allow us to 
embed assumptions in the parameter list, and we wanted the format of the parameter to 
remain the same to provide inter-level mapping, we were unable to prove some of type 
checking conditions. Solutions to this problem are left for future work. The current 
version of the inter-level mappings between our specifications can be seen in Figure 10. 
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Sec_Theory(arbitrary 
sequence) 


Assumptions 

1. Initial state in a sequence is secure 

2. The next state in a sequence results 
from a transform operation of the 
previous state 

3. If a state is secure, then every state 
that results from a transform operation] 
on that state is secure 


Theorem 

Every state in the sequence is secure 



1 . 

2 . 

3. 


4. 


Define a state in this specificatii 
Define a sequence of states 
The assumptions from Sec_theor}\ 
become proof obligations(TCCs) 
in State 

Add the necessary assumptions ^ 
to prove the proof obligations 



Expressions for 

Mapping 

Purposes 



. 1. Express a correspondence of the elements and 
components of the FTLSSpec to the elements 
and components of State explicitly 


Eigure 10. Current Inter-level Mapping Construction 


b. Mapping of Sec theory and the State Specifications 

Using the IMPORTING clause, we were able to map State to Secjheory 
as seen in Eigure 10. Proofs of the TCCs generated from this importation can be seen in 
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Appendix M. The IMPORTING elause was used to map State to Secjheory as seen 
below. In the State speeifieation, the names of the parameters remained the same, 
however the parameters were defined in State. 

Sec theory 

Sec theoryf Access State: TYPE, Transformlnstance: TYPE, seq: 

sequencefAccess_StateJ, SecState:[Access_State -> bool]. Transform: 

[Transformlnstance, Access_State -> Access_State]]: TEIEORY 

State 

IMPORTING S ecjheory[Access_State, Transformlnstance, seq, 

SecState, Transform] 

c. Expressions for Mapping the FTLS Specification to the State 

specification 

Sinee the system was unable to eonstruet the neeessary mapping theorems 
from our eurrent speeifications, we eonstrueted eomponents explieitly in FTLSSpec that 
eorresponded with the components of the State specification. We were able to form a 
correspondence between the elements of the specifications using the IMPORTING clause 
as illustrated in Figure 6. Refer to Appendix M and N to view the specifications. Figure 
11 is a diagram of the corresponding components of FTLSSpec and State as well as 
questions that arose when trying to provide inter-level mapping. Future research should 
be conducted so that the mapping between components is not explicitly stated and ideally 
the inter-level mapping should be performed as in Figure 9. 
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Mapping 
explicitly stated 


ProcTransform 




Transform 


How do 
Processes and 
Access _State 
correspond with 
each other? 


Proc Trans Inst 


SecProcesses 


Transformlnstance 


SecState 


How do 
SecProcesses 
and SecState 
correspond with 
each other? 


SecProcess 


SecureAccess 


When using the IMPORTING clause to map MemBlock to Object and 
Mode to Mode in the FTLSSpec and State, there was no association 
given between MemBlock and Mode. However, in the FTLSSpec, 
there is an association. This presents a problem when trying to 
develon inter-level mannine. 


How do 
SecProcess 
and 

SecureAccess 
correspond 
with each 
other? 


Figure 11. Inter-level Mapping Problem 


Sinee most of our researeh time was spent on building the frameworks of 
the formal seeurity poliey model speeifieation and the FTLS, the inter-level mapping 
eould not be eonstrueted sinee time was limited. However, whether this problem is based 
on the PVS system, the frameworks of our speeifieations, or inter-level mapping features 
of PVS that were unaware to us remains questionable. Sinee inter-level mapping 
between FTLSSpec and State eould not be eonstrueted, we were unable to analyze how 
easy it was to prove the mapping. Finding a solution to the inter-level mapping problem 
as well as analyzing how easy it is to prove that the FTLS mapped to the formal seeurity 
poliey model beeomes a problem to answer in future work. 
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C. LEVEL OF ASSURANCE PROVIDED 


Increasing the level of assuranee that a system provides can be achieved by 
redueing requirements errors by applying formal methods during the requirements phase. 
A formal method is a development method based on some formalism, sueh as a formal 
speeification notation or a formal analysis teehnique. A formal requirements speeifieation 
can reduce errors by redueing ambiguity and impreeision and by making some instances 
of inconsisteney and ineompleteness obvious. Formal analysis can detect many classes of 
errors in requirements speeifieations, some of them automatieally. Formal speeifications 
as a system deseription elarify requirements and high-level design, artieulate implieit 
assumptions, identify undoeumented or unexpeeted assumptions, expose flaws, and 
identify exceptions. Error detection techniques can be seen below. PVS supports all of 
the features below except for providing exeeutable speeifications. 

• Inspection of the formal speeifioation (manual) 

• Parsing for syntactic correctness (automated) 

• Type-eheeking for semantic consistency (automated) 

• Simulation/animation based on the speeifieation; This is only possible if 
the language provides an exeeution option 

• Theorem proving and proof-cheeking for logieal anomalies (interaetive) 

1. Consistency within each Specification 

The purely definitional style adopted and the strong typing mechanisms of PVS 
gave us strong assuranee eoneerning the internal consisteney of the speeifieations. If all 
the expressions that ean be proven in our speeifieation using the underlying logie are true 
then the logic is sound. The type cheeking eonditions to be proved are generated to assure 
sound definitions and demonstrate semantie eonsisteney. The type eheeking system 
offers some logical consistency from the type eheeker, however most of it is dependent 
on the manual inspeetion by the user. Completeness is when the speeification identifies 
all contingencies and speeifies appropriate behavior for all cases. Verification tools are 
used as an adjunet not a replacement for standard quality assuranee methods. Formal 
methods are not a panacea, but can increase confidence in a system’s reliability if applied 
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with care and skill. PVS, a verification tool is very useful for consistency checks, but 
cannot assure eompleteness of a speeifioation. Developing eonsistent and eomplete 
specifications is a complex, time eonsuming, and diffieult proeess. In many applications, 
the effort required to make the speeifieations both consistent and complete is not 
warranted, and a eonsistent set of speeifioations is often sufficient [Hei96]. 

2. Consistency between the FTLS and the Formal Security Policy Model 

Whether the FTLS was consistent with the Formal Security Policy Model remains 
unanswered since the proper inter-level mapping theorems that provide this eonsisteney 
ehecking could not be construeted. If the appropriate mapping theorems between these 
two specifications could be developed, then one could verily that there were no 
ineonsisteneies between the abstract design of the implementation (FTLS) and the State 
speeification. Also, since the system was unable to construct inter-level mapping from 
our speeifieations, we eould not show a proof of correspondenee between the FTLSSpec 
and State. Otherwise, bugs and unintended funetionality could become known and then 
eorreeted early in the design phase of the system. Currently, the level of assurance is low 
since one ean only verify the semantie and logieal eonsisteney within a specifieation. In 
addition, since PVS does not provide exeeutable speeifieations, one cannot simulate the 
speeifieations to see whether the required properties hold or to really analyze whether 
there is logical consistency. 

D. FUTURE WORK 

1, Solving the Inter-level Mapping Problem 

Future researeh should modify our given speeifieations so that they satisfy the 
ideal inter-level mapping construction as seen in Figure 9. Whether this problem is 
solvable remains questionable. Our empirieal study should be applied to the next 
qualified verifieation system, ACL2, and comparisons should be made to determine the 
most suitable system for speeific applieations. 

2, Background of A Computational Logic of Applicative Common Lisp 
(ACL2) 

a. Introduction 

ACL2 can be used as a programming language, a specification language, a 
modeling language, a formal mathematical logic, a semi-automatic theorem prover, and 
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more. It basically is a mathematical logic together with a mechanical theorem prover to 
help one reason in the terms of the logic. ACL2 is programmed in and supports the logic 
of a large applicative (“side effect free”) subset of Common Lisp. In other words, ACL2 
is a very small subset of full Common Lisp. Roughly speaking, a language is applicative 
if it follows the rules of function application [Moo03]. 

b. Semantics 

ACL2’s underlying logic is quantifier free first order logic. The semantics 
of ACL2 include macros that can be extended with a single-threaded state, fast 
applicative arrays, and property lists. The macro facility of Common Lisp can be used to 
make specifications more succinct and easier to grasp. The formal models that are written 
in ACL2 are executable except when there are undefined functions. It is possible to 
introduce an undefined function whose value is constrained to be some object satisfying a 
certain formula, provided such an object exists. This then extends the ACL2 logic to full 
first order logic. In addition, it is possible to introduce a function whose “body” is a 
universally (or existentially) quantified formula [Moo03]. 

ACL2 supports five disjoint kinds of data objects[Kau02]; 

• Numbers: 0, -123, 22/7, #c(2 3) 

• Characters: #\A, #\a, #\$, #\Space 

• Strings: “This is a string.” 

• Symbols: nil, x-pos, smith: :x-pos 

• Conses - (1 .2), (a b c), ((a . 1) (b . 2)) 

The primitive functions of ACL2 can be categorized as: 

• Boolean (e.g. (and pi p2...) : Logical conjunction operator 

• Arithmetic (e.g. ( + x y ) : Addition 

• Characters (e.g. (char - code char) : Convert character to integer 

• Strings (e.g. (length str) : Length of string (or list) 

• Symbols (e.g. (symbol-name sym) : Name (string) of symbol 
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• Cons Pairs and Lists (e.g. (cons x y) : Construct an ordered pair 

c. Guards/Other Features 

ACL2 presents itself to the user as “read-eval print loop” where it 
repeatedly reads an expression from the user, evaluates it, and prints the result. The 
expressions typed into the read-eval print loop are called top level expressions and these 
expressions are not allowed to eontain unbound variable symbols. ACL2 provides the 
ability for functions to compute and return multiple results and permits the use of 
declarations in certain expressions. These declarations are used to inform the Lisp 
eompiler and the ACL2 system about pragmatic issues. In addition, the Definitional 
Principle allows the user to add axioms defining new funetion symbols, under conditions 
that insure that the soundness of the logic is preserved. ACL2 ineludes the use of 
packages, eneapsulation, books, and theories that provide name and rule scoping. Since 
ACL2 is a programming language where hints and prover advice can be expressed and 
codified. ACL2 provides a powerful type-like meehanism called “guards” whieh ean be 
used to assure that funetions are “well typed”. Guard verification provides meehanized 
support for proving that functions are used in eomplianee with Common Lisp. 

d. Theorem Prover 

The automatic theorem prover is driven by an incrementally constructed 
database of previously proved theorems. Decision procedures are for propositional 
ealculus, equality, and linear arithmetic. There are integrated heuristics for congruence- 
based rewriting, backwards and forward chaining, destructor elimination, generalization, 
and induction. In addition, there are user supplied meta-theoretic simplifiers, an elaborate 
hint meehanism ineluding the use of Binary Decision Diagrams (BDDs), and a built-in 
interactive “proof checker”. The ACL2 prover is powerful and versatile with respect to 
problems couehed in its “native” domain of reeursively defined funetions[You96*]. Since 
ACL2 is both an executable programming language and a specification language for the 
theorem prover, it allows the theorem prover to argue about its own code [Kro02]. 

e. Concerns 

ACL2 does not support the hierarehical organization of theories, operator 
theories, and derived rules [Zha98]. It also is not based on higher order logie, and 
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therefore may not be suitable for a wider range of applieations. Sinee ACL2 is not only a 
programming language but also a logie, there are some restrictions on function 
definitions. For example, “global variables” are not allowed, any function used in the 
body other that the ones being defined must have been introduced earlier, and recursive 
definitions must be proved to terminate. While many programming languages have 
expressions, statements, blocks, procedures, or modules, etc., ACL2 just has expressions. 
The lisp syntax is sometimes a major stumbling block for many new users of ACL2, 
however it has the advantages of being completely unambiguous without any ancillary 
precedence rules [You96]. 

3. ACL2 vs. PVS 

a. Expressiveness 

i. Types 

The primary goal of a type system is to ensure language safety by 
ruling out all untrapped errors in all program runs [Car97]. The declared goal of a type 
system is usually to ensure good behavior of all programs, by distinguishing between 
well typed and ill typed programs. Types and subtypes correspond to basic constructs of 
specification languages and programming languages. Support for types and subtypes is 
preferable and there are many different kinds of subtypes. 

• Predicate subtype 

• Dependent subtype 

• Syntactic subtype 

• Semantic subtype 

Of all languages, PVS has the most expressive type system that 
consists of a base type and a predicate. The base type is a basic type such as the number 
type or an enumerative type, or combinations of basic types (tuples, records,...). 
Subtyping helps for writing understandable and concise specifications. ACL2 does not 
support a type system and its syntax is that of Common Lisp. Lisp derives much of its 
expressive utility from its weak typing, even though considerable execution efficiency 
can be gained from type declarations [You96*]. 
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ii. Underlying Logic/Syntax 

Higher order logie ensures that the specifieation language applies 
to the widest range of applieations. The use of a more restrictive logic such as first order 
logic means that more effort sometimes must be invested in the specification but is often 
repaid with increased automation in the proof. In addition, higher order logic is elegant 
but seldom necessary, and higher orderness may be a notational convenience[You96*]. 
The elegance gained in specification must be weighed against the potential additional 
proof burden. Most lambda terms can be translated directly into recursive functions 
though often at the cost of additional parameters. In addition, sometimes the appropriate 
recursive function serves the purposes of a quantifier. ACL2 is essentially quantifier-free, 
first order logic. It is not as usable as PVS and has limited or no support for arbitrary 
quantification. PVS offers higher order functions, strong typing, lambda abstraction, and 
full quantification. These uses can easily be translated into simpler logical constructs that 
facilitate more automated proof discovery. 

The syntax of ACL2 is that of Common Lisp, macros however 
make this syntax extremely malleable. ACL2 has both recursive and induction function in 
its syntax. ACL2 supports the macro facility of Common Lisp. Macros provide a 
powerful abbreviation facility and can be used to make specifications much more 
succinct and easier to grasp [You96*]. All the functions evaluate their arguments. ACL2 
also supports the introduction of axiomatically constrained function symbols that have no 
executable counterpart. In ACL2, a macro package can be introduced to add enumerated 
types to a specification. Record structures can be easily represented in ACL2 using the 
available def-structure macros. Also, ACL2 integrates its untyped logic with guards to 
insure compliance with efficiently executable raw Lisp implementations. ACL2 
provides execution of definitions and encourages concrete, efficient models. PVS cannot 
simulate machine execution conveniently but supports higher-order logic and encourages 
specifications unburdened by irrelevant detail. 
b. Theorem Prover 

The proof of a theorem is an unbroken chain of inferences that connect 
that theorem to axioms. Both ACL2 and PVS support the ability to do backward proofs. 
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forward proofs, proof by rewrite, proof by induction, and proof by cases. In addition, 
ACL2 is able to perform proofs by contradiction. Theorem proving tools that are based 
on first order logics become very restrictive, therefore tools that are based on higher order 
logic such as PVS can be more desirable 

ACL2 provides several automatic proof techniques that the user programs 
by proving theorems and then adding these theorems to the theorem prover database. 
The style of these proofs has an important benefit that is proof robustness. Since these 
proofs are “automatic”, dramatic changes in the specification or system does not imply 
that the proofs will change drastically. Theorem provers that are based on first-order 
quantifier free logic are appropriate tools when working on large systems that have had 
corrected problems due to the mostly automatic approach to guiding the theorem prover. 

PVS has support for automated reasoning, namely a simple rewriting 
system and a facility for constructing new proof commands. PVS can also be used to 
reason about computer systems in a robust style. Realistic proofs require robustness and 
PVS is capable of a proof style that fosters resilience in proofs about computer systems 
[Wil97]. 

E. CONCLUDING REMARKS 

Our empirical study of PVS paved the way for future research of other 
verification systems. The methodology we used for the evaluation of PVS can be 
followed for the analysis of the next selected verification system. Since ACL2 was our 
second choice for our empirical study due to the relevant documentation, satisfied 
evaluation criteria, and our familiarity with the tool, its evaluation is the next step in 
future research. In the previous sections, ACL2’s background and comparisons with PVS 
has been introduced. In this section, the proper methodology for an empirical study of 
ACL2 will be provided as well as a table summarizing the features of ACL2 that should 
be observed in the research process. The summation will be based on the features of PVS 
in comparison to ACL2. This is due to the fact that the main purpose of our work was to 
introduce a verification system that would be suitable for the project HANNAH (High 
Assurance Network Authenticator), which involves the creation of a high assurance 
trustworthy authenticator on a network. The policy we have used in our paper is a 
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simplified version of a complex policy that may be used when implementing HANNAH. 
HANNAH requires the use of a verification system, and therefore relies on the results of 
the evaluation of the verification systems. Therefore, more verification systems need to 
be evaluated to figure out the most appropriate verification system that should be applied 
to HANNAH. By following the same methodology used in our study, a better analysis 
can be conducted to compare the different verification systems. 

1. Methodology for Future Work 

First, our formal security policy model should be used when constructing the 
formal security policy specification. When developing the specification in the language 
of ACL2 that is supposed to represent the formal security policy model and the FTLS, 
there are specific elements, functions, theorems, etc. that are required. 

The formal security policy specification should have the following elements: 

• Subjects 

• Objects 

• Access Attributes {read, write} 

• Security Levels (Top Secret, Secret, Classified, Unclassified) 

The formal security policy specification should have the following components: 

• Current Access set 

• Access Matrix 

• Security Level function - Mapping Subjects and Objects to Security 

Labels 

The formal security policy specification should have the following properties: 

• A subject 5 is allowed to read an object o only if the security label of 5 
dominates the security label of o - no read up and applies to all subjects 

• A subject 5 is allowed to write an object o only if the security label of o is 

equal to the security label of 5 

• Strong tranquility 
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The formal security policy specification should have the following rules: 

• State transition operators 

o Add to and delete from the current set of accesses 

The formal security policy specification should have the following theorems and 
proofs: 

• The Basic Security Theorem that states that if the initial state (where state 
is the current set of accesses) is secure, and every state that results from 
some operation is secure, then every state is secure. 

The formal top-level specification should have the following elements: 

• ProcessID 

• Memory Block 

• Access Attributes {read, write} 

• Security Levels (Top Secret, Secret, Classified, Unclassified) 

The formal top-level specification should have the following components: 

• Component that maps to the Current Access Set 

• Component that maps to the Access Matrix 

• Security Level function - Mapping Processes and Memory Blocks to 
Security Labels 

The formal top-level specification should have the following properties: 

• A process p is allowed to read an a memory block m only if the security 
label of p dominates the security label of m - no read up and applies to all 
processes 

• A process p is allowed to write a memory block m only if the security label 
of p is equal to the security label of m 

• Strong tranquility 
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The formal top-level specifieation should have the following rules: 


• State transition operators 

o Add or delete a memory bloek from a proeess 
The formal top-level specification should have the following theorems and proofs: 

• Theorems that prove the inter-level mapping between the FTLS and the 
formal security policy model specification 


Learning the specification language of ACL2 and understanding how to use the 
theorem prover can take some time. However, the essential requirements of the 
specifications as well as our PVS specifications themselves are given as a reference that 
can reduce the amount of time and work. Choosing an appropriate verification system is 
essentially based on the preferences of the user of the system. It is the user whose criteria 
should be satisfied since he is the one interacting with the system. For example, a user 
with knowledge of Lisp has an advantage when using ACL2 since that person does not 
have to learn the specification language. 

If the inter-level mapping problem cannot be resolved using the PVS system, 
then it should not be considered as an eligible system for the specified applications. 
However if both ACL2 and PVS support inter-level mapping then the criteria in Table 6 
should be weighed to determine how the selection process should be handled. Once inter- 
level mapping is demonstrated, one can extrapolate from these results a conclusion about 
the usefulness of a verification system for the verification of real world systems. The 
work that has been done in this thesis demonstrates new research that has not been 
addressed in any PVS documentation that we have read. Therefore, the problems we 
have come upon as well as the ideas we have brought forth should be assessed and used 
in future work. 
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ACL2 

PVS 

Age 

Current Version 2.7 in 
2002 first developed 
around 1994 

Current Version 3.1 in 
2003, first developed 
around 1992 

Purpose 

General purpose theorem 
prover 

General purpose theorem 
prover 

Implementation Language 

Untyped Common Lisp - 

? 

Common Lisp - not very 
difficult to understand the 
theorem prover commands 
or messages 

Resource Requirements 

ACL2 works on the Unix, 
some variants including 
Linux, and Macintosh OS. 

It is built on top of any of 
the following Common 
Lisps: Allegro, GCL (Gnu 
Common Lisp) [or, AKCL], 
Lispworks, Lucid, and MCL 
(Macintosh Common Lisp) 

PVS 3.1 is currently 
available only for Sparc 
machines with Solaris 2 
and Intel x86 Machines 
with Linux compatible with 
Redhat 5 or later. 

User-Friendly 

Automatic theorem prover, 
user defined proof 
strategies, provides 
decision and inference 
strategies and previously 
proved theories, theorem 
prover can argue about its 
own code since ACL2 is 
both an executable 
programming language and 
a specification language 
? 

Proofs are generated 
interactively, user defined 
proof strategies can also be 
invoked, interface is easy to 
understand, theorem prover 
command are 
straightforward and proof 
construction is not difficult, 
provides decision and 
inference strategies and 
previously proved theories, 
specification language and 
implementation language 
are not difficult to 
understand 

User Interface 

Emacs - ? 

Gnu Emacs, Xemacs - 
Requires planning of proof 
strategy however organized 
in proof structure 


Table 6. Comparison between ACL2 and PVS (Questions Marks to be answered by future 

researeh) 
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ACL2 


PVS 


User Presentation 
Language 

Common Lisp ? 

Its own presentation 
language - Able to express 
the necessary properties, 
succinct and easy to 
understand 

Consistency of 
Specifications 

Yes, Interactive consistency 
? 

Yes, automated consistency 
checking of specifications - 
Type checking system 

Executable Specifications 

Yes, specifications may be 
executed in an underlying 
implementation of Common 
Lisp; thus can build 
executable specifications 

No 

Multiple Levels of 
Abstractions 

Yes - ? 

Yes - using the 
IMPORTING clause to 
map one specification to 
another 

Expressiveness 

First Order Logic - results 
in unambiguous 
specifications and can 
increase the automation of 
the proof, the macros 
facility can be used to make 
specifications more succinct 
and easier to grasp; No 
Type System - ? 

Higher Order Logic - 
wider range of 
applications, more 
expressive, elegant but 
most of the time 
expressions in HOT can 
also be expressed in FOL; 
Type System - increases 
amount of flexibility and 
increases the precision of 
the specification System 


Continuation of Table 6 -Comparison between ACL2 and PVS 
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APPENDIX A: AGE 


ACL2 

Current Version 2.7 2002, first started around 1994 

AutoFOCUS 

First developed in 1996 

Coq 

Current version 7.3.1 2002, first started 2001 

Elf/Twelf 

Current Version 1.3, first started in 1998 

HOL 

Latest Version now called HOL 4, First version came out in 1988 

IMPS 

Current version 2.0, first started in 1990 

Isabelle 

Current Version 2002, first distributed in 1986 

Nuprl 

Current Version 2002, first developed in 1984 

Otter 

Current Version 3.1 in 2000, first started in 1995 

PVS 

Current Version 3.1 in 2003, first developed in 1992 

SpecWare 

Phase 2 


83 














STeP 


Developed in 1994 

TAME 

Developed around 1997 

TPS 

Current Version 2000, first developed in 1990 

Vienna 

Developed around 1978 - not sure if updated sinee 1996 
Z/Eves 

Current Version 2.1 in 2002, first started in 1990 


84 








APPENDIX B: PURPOSE 


ACL2 


ACL2 is a general purpose theorem prover that can be used to verify every step of a proof 
in almost any mathematical domain, from real analysis to circuit design. It is a stable and 
robust system designed to tackle industrial-size verification projects 

AutoFOCUS 


AutoFocus is based on formal methods of systems engineering. It will serve as start point 
and evaluation means for further tool concepts for the specification and development of 
distributed systems. 

Coq 


Coq is used for extracting programs from proofs. 

Elf/Twelf 


Elf/Twelf is a system based on predicative type theory that can be used to specify and 
reason about logics, languages, type systems, etc. 

HOL 


The HOL system has a wide variety of uses from formalizing pure mathematics to 
verification of industrial hardware. Academic and industrial sites world-wide are using 
HOL. 

IMPS 


IMPS is a interactive mathematical proof system intended to provide organizational and 
computational support for the traditional techniques of mathematical reasoning. 

Isabelle 


Isabelle allows for single-step proof construction and provides control structures for 
expressing search procedures. Isabelle also provides several generic tools, such as 
simplifiers and classical theorem provers, which can be applied to object logics. 

Nuprl 


Nuprl is a computer system which provides assistance with problem solving. It supports 
the interactive creation of proofs, formulas, and terms in a formal theory of mathematics. 
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With it one can express concepts associated with definitions, theorems, theories, books 
and libraries. 

Otter 

Otter is currently an automated deduction system. Otter is designed to prove theorems 
stated in first-order logic with equality. 

PVS 

PVS is a general purpose theorem proving tool. 

SpecWare 

Specware is a next-generation environment supporting the design, development and 
automated synthesis of scalable, correct-by-construction software. 

STeP 


STeP is a tool for the computer aided formal verification of reactive systems, including 
real-time and hybrid systems based on their temporal specification. 

TAME 


A major goal of TAME is to allow a software developer to use PVS to specify and prove 
properties of an I/O automaton efficiently and without first becoming a PVS expert. 

TPS 

TPS is an automated theorem-prover for first-order logic and type theory. 

Vienna 

Vienna is a collection of techniques for the formal specification and development of 
computing systems. It supports the top-down development of software systems specified 
in a notion suitable for formal verification. 

Z/Eves 


Z/Eves is a formal methods tool to incorporate a unique set of technologies. It is a proof 
obligation generator, an automated deduction system, and interactive theorem prover. 
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APPENDIX C: IMPLEMENTATION LANGUAGE 


ACL2 

Untyped Common Lisp 

AutoFOCUS 

Java 

Coq 

ML 

Elf/Twelf 

Standard ML 

HOL 

Standard ML 

IMPS 

Common lisp 

Isabelle 

Standard ML 

Nuprl 

ML 

Otter 

C 

PVS 

Common Lisp 
SpecWare 
PHASE 2 
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STeP 


ML 

TAME 

Interface to PVS 

TPS 

Common Lisp 

Vienna 

VDM-SL, VDM++ 
Z/Eves 
Common Lisp 
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APPENDIX D: RESOURCE REQUIREMENTS 


ACL2 


ACL2 works on Unix and some variants including Linux, and Macintosh OS 

AutoFOCUS 


Unix platforms 

Coq 


The current stable version of Coq is the 7.3.1. It currently is available for Unix (including 
Mac OS X) and Windows 95/98/NT systems. It also runs on several operating systems 
including Linux, Solaris, and Windows. 

Elf/Twelf 


Elf is implemented in Standard ML of New Jersey, which runs on a variety of 
architectures; it requires version 0.72 or greater. 

HOL 


Unix and Windows machines 

IMPS _ 

IMPS runs on Linux and Solaris platforms. IMPS 2.0 should work with most versions of 
Common Lisp. 

Isabelle 


Unix platforms; A minimal Isabelle installation requires only bash and perl (usually 
provided by the operating system), and a suitable implementation of Standard ML; A 
comfortable Isabelle working environment demands further user interface support. 

Nuprl 


Nuprl should run in any Common Lisp with CLX. There are also interfaces for 
Symbolics Lisp machines and Suns running the SunView window systems. 

Otter 


It has been used mostly on UNIX systems, but limited versions also run on PCs and 
Macintoshes. 


89 



PVS 


PVS 3.0 is currently available only for Sparc machines with Solaris 2 and Intel x86 and 
for maehines with Linux compatible with Redhat 5 or later. 

SpecWare 

Phase 2 

STeP 

STeP runs on SUN spare 20, and UltraSpare under SOLARIS, DEC Alpha under IRIX, 
SGI under IRIX5, and x86 under LINUX 

TAME 

Same as PVS 

TPS 

Unix and Linux systems, and to some extent under Windows 

Vienna 

Unix platforms 

Z/Eves 

Z/Eves runs on Einux, Windows 95/98/NT and Solaris 


90 



APPENDIX E: USER-FRIENDLY 


ACL2 


It is not easy to get ACL2 to prove hard theorems. A user must understand the model, 
ACL2 as a mathematical logic, and be able to construct a proof (in interaction with 
ACL2). ACL2 will help construct the proof, but its primary role is to prevent logical 
mistakes. A user’s responsibility is the creative burden or the mathematical insight why 
the model has the desired property.[Moo03] 

AutoFOCUS 


AutoFOCUS offers user support by using a specification pattern, a model-based editor, 
and consistency checks. 

Coq 


Coq allows for interactive construction of proofs. 

Elf/Twelf 


Elf/Twelf allows the user to program algorithms and express their correctness proof 
within the same language. It is not well suited for interactive development of theories. 

HOL 


Beginning users can rapidly start doing proofs using HOL. It is similar to PVS since it 
combines model checking with user guided interactive proof HOL users have to learn 
some ML before using the system. 

IMPS 


IMPS provides user guided interactive proofs. The course of machine deduction is 
orchestrated and controlled by the user. Users can formulate mathematical concepts and 
arguments in a natural and direct manner. Theory interpretations between the theory 
multiples are created when needed by the user. The user has great freedom to decide in 
order in which he wants to work on different subgoals. It is an effective tool to a wide 
range of mathematically educated users. [Par95] 

Isabelle 


Isabelle allows for single step proof construction. Beginners can get by with a small 
repertoire of commands and a basic knowledge of how Isabelle works. 
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Nuprl 


Nuprl supports interactive creation of proofs, formulas, and terms in a formal theory of 
mathematics. It has an interactive style of proof checking that characterizes Nuprl. In this 
system it is impossible to develop an incorrect proof It has characteristics of an 
intelligent computer system in that it provides its users w/a facility for writing proof 
generating programs in ML.[Koh99] 

Otter 


Otter is an automated deduction system that is designed to prove theorems stated in first 
order logic with equality. 

PVS 


In PVS proofs are generated interactively and user defined proof strategies can also be 
invoked. 


SpecWare 


PHASE 2 

STeP 


In STeP, proofs can entirely be automatic or can be user directed. 

TAME 


TAME provides a template that the user completes to specify an I/O automaton and a set 
of proof steps natural for humans to use for proving properties of automata. Each proof 
step is implemented by a PVS strategy and possibly some auxiliary theories that support 
that strategy. Users can create proofs using “natural” or automatic proof steps, without 
learning the details of the PVS proof steps. TAME also provides better user feedback that 
that provided by PVS.[Arc01] 

TPS 


TPS can be proved automatically, interactively, or in a mixture of these modes. The 
automatic mode is quite primitive since it deals with equality. 

Vienna 


In Vienna, a small change between concrete specifications and code leads to a 
straightforward implementation, automatic code generation, and a descriptive language. 
However, VDM is still relatively difficult to use. 
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Z/Eves 


NEVER is the automated deduetion eomponent of EVES. It is an interaetive theorem 
prover that is eapable of automatieally performing large proof steps, yet ean be finely 
direeted by the user. NEVER is neither a fully automatie nor an entirely manual theorem 
prover. Although NEVER provides powerful deduetive teehniques for the automatie 
proof of theorems, it also ineludes simple user steps that permits its use as a system more 
akin to a proof eheeker than a theorem prover. The possible fine eontrol of the prover 
allows users to elosely investigate proof strategies and determine why, for example, 
proofs are failing.[Koh99] 
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APPENDIX F: USER INTERFACE 


ACL2 

Emacs 

AutoFOCUS 

Project browser for the organization of the specification documents of the single project, 
and one editor for each specification document 

Coq 

Standard teletype-like shell window; does not use any special interface such as Emacs or 
Centaur 

Elf/Twelf 

Standard ML interface or Emacs mode 

HOL 

Xhol, chol, emacs 

IMPS 

Emacs-based interface 

Isabelle 

ML/user interface 

Nuprl 

Xwindows 

Otter 

Xwindows 

PVS 

Gnu Emacs, Xemacs 

SpecWare 


95 



Phase 2 

STeP 

Xwindows 

TAME 

Friendly user interfaee - interfaee to PVS 

TPS 

Phase 2 

Vienna 

Phase 2 

Z/Eves 

Graphieal interfaee-allows two speeifioations to be entered and edited 
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APPENDIX G: USER PRESENTATION LANGUAGE 


ACL2 

Common Lisp 

AutoFOCUS 
Phase 2 
Coq 
Phase 2 
Elf/Twelf 
Phase 2 
HOL 
Phase 2 
IMPS 
Phase 2 
Isabelle 
Phase 2 
Nuprl 

Common Lisp 

Otter 

Phase 2 

PVS 

It has its own presentation language 

SpecWare 
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Phase 2 


STeP 

Phase 2 
TAME 
Phase 2 
TPS 
Phase 2 
Vienna 
Phase 2 
Z/Eves 
Phase 2 
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APPENDIX H: CONSISTENCY OF SPECIFICATIONS 


ACL2 

Yes, interactive consistency 

AutoFOCUS 

Phase 2 

Coq 

May cause ambiguity 

Elf/Twelf 

Consistency is unclear 

HOL 

Yes 

IMPS 
Phase 2 
Isabelle 
Yes 

Nuprl 

Yes, has consistency proof of formal specifications 

Otter 

Phase 2 

PVS 

Yes, automated consistency checking of specifications 

SpecWare 

Phase 2 
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STeP 


Phase 2 

TAME 

Yes, automated eonsisteney of speeifieations 

TPS 

Phase 2 

Vienna 

Phase 2 

Z/Eves 

Yes, has a eonsisteney cheeker 
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APPENDIX I: EXECUTABLE SPECIFICATIONS 


ACL2 

Yes, specifications may be executed in an underlying implementation of Common Lisp; 
thus can build executable specifications 

AutoFOCUS 

Phase 2 

Coq 

Yes, there are papers about efficient reasoning about executable specifications 

Elf/Twelf 

Many specifications are not executable under the traditional logic programming 
semantics and performance may be hampered by redundant computation. 

HOL 

Yes, hoi, hol.bare, hol.unquote, and hol.bare.unquote 

IMPS 
Phase 2 
Isabelle 
Phase 2 

Nuprl 

Yes, functional language for executable specifications 

Otter 

Phase 2 

PVS 

No 

SpecWare 
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Phase 2 
STeP 
Phase 2 
TAME 
Phase 2 
TPS 
Phase 2 
Vienna 

You ean write exeeutable and non-exeeutable speeifieations in VDM-SL 

Z/Eves 

Phase 2 
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APPENDIX J: MULTIPLE LEVELS OF ABSTRACTION 


ACL2 

Yes 

AutoFOCUS 

Phase 2 

Coq 

Phase 2 

Elf/Twelf 

Phase 2 

HOL 

Yes 

IMPS 

Yes 

Isabelle 

Phase 2 

Nuprl 

Phase 2 
Otter 
Phase 2 
PVS 
Yes 

SpecWare 

Phase 2 
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STeP 


Phase 2 
TAME 
Phase 2 
TPS 
Phase 2 
Vienna 
Phase 2 
Z/Eves 
Phase 2 
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APPENDIX K: EXPRESSIVENESS 


ACL2 


ACL2 blends arithmetic decision procedures with rewriting techniques and it supports 
rational numbers, complex rationals, character objects, character strings, and symbol 
packages. Formal models written in ACL2 are usually executable unless they are 
undefined functions. ACL2 has a powerful type - like mechanism called “guards” which 
can be used to assure that functions are “well-typed”. Since it is programmed in the same 
logic it supports, it can ensure that the logic is a practical means of building large formal 
systems. Its logic is first-order quantifier free, its semiautomatic, and it uses lemmas as 
guidance. In addition, it has many design procedures (prepositional calculus, equality, 
arithmetic) and heuristics. Also, it has a built-in interactive “proof checker”.[Koh99] 

AutoFOCUS 


AutoFOCUS has formal, logical foundations, mathematical models and methods for 
distributed systems. It is based on traces and stream processing functions(combine 
functions and states). It creates consistency checks and supports simple temporal 
logic. [Tum03] 

Coq 


Coq is a higher-order proof system where proofs and terms are in a pure functional 
language. The basic specification language is called Gallina, in which formal 
axiomatisations may be developed. It is a non-conservative extension of the Calculus of 
Constructions with inductive types and is well adapted to inductive reasoning and has a 
powerful type system. It can also be described as a directed tactics theorem-prover with a 
set of predefined tactics, including an auto tactic that tries to apply precious lemmas 
declared as hints. Coq offers program extraction where the logic mixes a constructive 
logic and a classical logic. The system automatically extracts the constructive contents of 
proofs as an executable ML program. [Koh99] 

Elf/Twelf 


Elf/Twelf is a LF logical framework based on a predicative type theory. It lends itself to 
the very direct specification of programming languages, type systems, logics, etc. One 
then can program algorithms and express their correctness proof within the same 
language. Features that make it unique are the internal notion of deduction and the 
expressive language of types (which include dependent types). These together can be 
exploited to implement the meta-theory of programming languages, compiler, logics, etc. 
All data is developed and stored as programs. It employs a sophisticated term 
reconstruction algorithm that allows much of the input information to be elided without 
any syntactic restrictions.[Koh99] [ Pfe03] 
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HOL 


HOL’s most outstanding feature is its high degree of programmability through the meta¬ 
language ML. The seope of type variables is the current term in HOL and type-checking 
includes simple typechecking. In addition, it has more emphasis on logical foundations 
and less on usability. HOL does not support typechecking with respect to predicate 
membership. A primary use of HOL is the building of special purpose proof 
infrastructure. Users can add external tools to HOL and embed languages just by 
programming in ML. The HOL System is an environment for interactive theorem proving 
in a higher order logic.[Koh99] [ Iyo03] 

IMPS 


The logic of IMPS is based on a version of simple type theory with partial functions and 
subtypes. Automated analysis, computing with theorems, higher order logic, theory 
interpretation, mathematical specification and inference are performed relative to 
axiomatic theories. IMPS provides relatively large primitive inference steps to facilitate 
human control of the deductive process and human comprehension of the resulting 
proofs. There is a library containing almost a thousand repeatable proofs that covers 
significant portions of logic, algebra and analysis. [Far95] 

Isabelle 


Isabelle is a generic theorem prover instantiated to support reasoning in several object 
logics: 1. First order logic, constructive, and classical versions, 2. Higher order logic 
compared to HOL, 3. Zermelo Fraenkel set theory, 4. Extensional version of Martin Lofs 
Type Theory, 5. The classical first order sequent calculus, 6. The modal logics T, S4, 
S43, 6. The logic for computable functions; Isabelle borrows ideas of LCF where 
formulas are ML values, theorems belong to abstract types, and tactics support backward 
proofs. However, object level rules are represented by terms not functions. Isabelle 
theorem proving can involve writing ML code. [Pau02] 


Nuprl 


The logic has a constructive semantics in that the meaning of propositions is given by 
rules of use and in terms of computation. One of the salient features of it is that the logic 
and the system take account of the computational meaning of assertions and proofs. For 
instance, given a constructive existence proof, the system can use the computational 
information in the proof to build a representation of the object which demonstrates the 
truth of the assertion. It supports an interactive environment for text editing, proof 
generation and function evaluation. It has an interactive style of proof checking that 
characterizes it. In this system it is impossible to develop an incorrect proof. It has 
characteristics of an intelligent computer system in that it provides its users with a facility 
for writing proof—generating programs in a metalanguage, ML. The style of the logic is 
based on the stepwise refinement paradigm for problem solving in that the system 
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encourages the user to work backwards from goals to subgoals until one reaches what is 
known. [Koh99] [Cor03 ] 


Otter 


Otter supports first-order logic with equality. Otter's inference rules are based on 
resolution and paramodulation, and it includes facilities for term rewriting, term 
orderings, Knuth-Bendix completion, weighting, and strategies for directing and 
restricting searches for proofs. Otter can also be used as a symbolic calculator and has an 
embedded equational programming system. The main application of Otter is research in 
abstract algebra and formal logic. Otter and its predecessors have been used to answer 
many open questions in the areas of finite semigroups, ternary Boolean algebra, logic 
calculi, combinatory logic, group theory, lattice theory, and algebraic geometry.[Arg03] 

PVS 


PVS supports classical higher-order logic with functions, sets, records, tuples, predicate 
subtypes, dependent typing, and theories with type and individual parameters. Axioms 
may be introduced freely and definitions (which may be recursive and include 
recursively-defined abstract data types and inductively defined predicates) provide 
conservative extension. It is an expressive specification language that allows concise and 
natural specifications across a wide range of problem domains. It also has a rich type 
system and very strict typechecking allows much of the specification to be embedded in 
the types with proof obligations generated automatically by the typechecker. There is a 
synergistic interaction between theorem proving and typechecking. PVS is an effective 
interactive theorem prover that combines powerful arithmetic decision procedures and 
other "large" primitive inference steps. PVS has the ability to display "humanly readable" 
proofs. [Koh99] [Sri03] 


SpecWare 


SpecWare supports automation of component-based specification of programs using a 
graphical interface, incremental refinement of specifications into correct code in various 
target languages (e.g. C++, LISP, Ada, Cobol), design and synthesis of software 
architectures/frameworks, and design and synthesis of algorithm schemas. In addition, it 
supports design and synthesis of reactive systems, data-type refinement, program 
optimization, recording and experimenting with different design decisions, domain- 
knowledge capture, verification and manipulation. [Kes03] 

STeP 


STeP integrates methods for deductive and algorithmic verification, including model 
checking, theorem proving, automatic invariant generation, abstraction and modular 
reasoning. [Sta03] 
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TAME 


TAME provides two types of strategies: strategies for “automatie” proof and strategies 
designed to implement “natural” proof steps, i.e. proof steps that mimie the high-level 
steps in typieal natural language proofs. It is a general-purpose higher-order logie 
theorem prover that uses standard logie.[AreOl] 

TPS 


TPS supports first and higher -order logie. It has faeilities for searehing for expansion 
proofs, translating these into natural deduetion proofs, eonstrueting natural deduetion 
proofs, translating natural deduetion proofs whieh do not eontain outs into expansion 
proofs, and solving unifioation problems in higher-order logie. It has a formula editor 
whieh faoilitates eonstrueting new formulas from others already known to TPS, and a 
library faoility for saving formulas, definitions, and modes (groups of flag settings). It oan 
operate in automatie, semi-automatio or interaotive mode and it’s logieal language is that 
of typed lambda-ealeulus. It has two proving eomponents: seareh for an expansion proof, 
and meta language for defining taeties and eonstrueting natural deduetion proofs. It is 
eontrolled by setting of over 150 user settable flags and it has a formula editor, library 
faoility for saving formulas, definitions, and modes. [AndOO] 

Vienna 


VDM-SL has a formally defined semantios. The logie underlying this semantios is based 
on the Logie of Partial Funotions (EPF). The definition of the semantios is given in a 
denotational style in the VDM-SL Standard. It has rules for data and operation refinement 
whieh allows one to establish links between abstraot requirements speoifioations and 
detailed design speoifioations down to the level of oode. It has a proof theory in whieh 
rigorous arguments oan be oonduoted about the properties of speoified systems and the 
oorreotness of design deoisions. In addition, it uses a speoifioation notation that is similar 
to Z. Its formal speoifioations is ISO-VDM - SL. [Ibm03] 

Z/Eves 


Z/Eves inoludes a graphioal user interfaoe that allows Z speoifioations to be entered, 
edited, and analyzed in their typeset form. It supports the inoremental analysis of 
speoifioations and manages the synohronization of the analysis with modifioations to the 
speoifioation. In addition, it supports untyped first -order logie, without the oonventional 
distinotion between terms. EVES has a meohanism for defining new funotions and every 
deolaration must be proved to define a oonservative extension of the theory in whieh it 
appears. There is also a library system that allows theories to be oombined. It oombines 
the power of its automatie oapabilities (embodied in the reduotion oommands) with the 
ability of the user to have fine-grained oontrol (using oommand modifiers and low level 
inferenoe oommands). We view the unique attributes of EVES as being the oombination 
of (i) an expressive formal speoifioation and programming language, (ii) praotioal 
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automated deduction support, (iii) mathematical soundness, (iv) rigorous tool 
development, and (v) availability on workstations and PCs. [Koh99] [Ora03] 
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APPENDIX L: DEVELOPERS/SUPPORT 


ACL2 

Editors Kaufmann and Moore, 

Contact persons:moore@cs.utexas.edu,kaufmann@aus.edsr.eds.com 

AutoFOCUS 

Department of Computer Science, TU Munchen 

Coq 

INRIA Rocquencourt and ENS Eyon 

Elf/Twelf 

Mark Pfenning at Carnegie - Mellon University 

Contact: Frank Pfenning, School of Computer Science, CMU - there is a mailing list with 
announcement of new papers and implementation releases of Elf 

IMPS 

Mitre corporation 

HOL 

Cambridge university, computer laboratory 

Isabelle 

Cambridge University and TU Munich 

Nuprl 


Department or Computer Science, Cornell University 

Otter 

Argonne national laboratory 

PVS 

SRI International 
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SpecWare 

Kestrel institute 

STeP 

Stanford University 

TAME 

Naval Researeh Laboratory 

TPS 

Carnegie Mellon University 

Vienna 

IBM Vienna Laboratory 

Z/Eves 

ORA Canada 
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APPENDIX M: SEC_THEORY, SLABELS, STATE SPECIFICATIONS 


Sec_theory[Access_State: TYPE, Transformlnstance: TYPE, seq: 
sequencefAccess State], SecState:[Access_State -> bool]. Transform: 
[Transformlnstance, Access State -> Access State]]: THEORY 
BEGIN 
ASSUMING 
St: VAR Access State 

x: VAR Transformlnstance 

n: VAR nat 


% Assumptions needed to form an inductive proof 

transition state secure: ASSUMPTIONSecState(st) => SecState(Transform(x, st)) 

seq O secure: ASSUMPTION SecState(nth(seq, 0)) 

% there exists a transform that will take the system from state n to n+1 

seqtransform: ASSUMPTION 
EXISTS x: nth(seq, n +1) = Transform(x, nth(seq, n)) 

ENDASSUMING 

% Every state in the sequence is a secure state 

seq is secure: THEOREM every(SecState)(seq) 

END Sec theory 


SLabels: THEORY 
BEGIN 

Label: TYPE+ = {i:nat \ i <=4 AND i > 0} CONTAINING I 

U: Label = I 
C: Label = 2 
S: Label = 3 
TS: Label = 4 

END SLabels 


StatefSubject: TYPE+, Object: TYPE+, (IMPORTING SLabels) slSubject: 
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[Subject -> Label], slObject: [Object -> Label], Action: TYPE+, 
addit: Action, del: Action, no op: setof[Action], Mode: TYPE+, rd: Mode, wr: 
Mode]: THEORY 
BEGIN 

% Assumptions needed to prove proof obligations 

ASSUMING 

AddDelNotNo_Op: ASSUMPTION 
NOT member(addit, no op) AND NOT member(del, no op) 

AddnotDel: ASSUMPTION NOT addit = del 

RdnotWr: ASSUMPTION NOT rd = wr 

ENDASSUMING 

Access: TYPE = 

[# u: Subject, f: Object, m: [x: Mode \ x = rd OR x = wr] #] 

Access State: TYPE = setof[Access] 

Transformlnstance: TYPE = [# ac: Action, a: Access #] 

% Verifies that an access is secure for a specific mode by comparing security 
% labels of the subject and object 

SecureAccessja: Access): bool = 

COND a'm =rd -> slSubject(a'u) >= slObject(a'f), 
a'm=wr -> slSubject(a'u) = slObject(a'f) 

ENDCOND 

% If all accesses in an Access _State are secure, then the Access _State is 
% secure 

SecStatejst: Access State): bool = 

EORALL (a: Access): memberja, st) => SecureAccess(a) 

% If a tranform is to add an access to an Access _State and the access to be added is 
% secure then add that access to the Access _State. If a transform is to delete an access 
% from an Access _State and the access is already in the state, then remove the access 
% from the Access_State 

Transformjc: Transformlnstance, st: Access_Statc): Access State = 

COND e'ac = addit AND SecureAccess(e'a) -> add(e'a, st), 
e'ac = del AND st(e'a) -> remove(e'a, st), 
memberje'ac, no op) -> st, 

ELSE -> st 
ENDCOND 

fs: sequence[Access_State] 
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fs_0_secure: AXIOMSecState(nth(fs, 0)) 
n: VAR nat 

fstransform: AXIOM 

EXISTS (e: Tmnsformlnstance): nth(fs, n +1) = Transform(e, nth(fs, n)) 

transitionstatesecure: AXIOM 
(FORALL (st: Access State, e: Transformlnstance): 

SecState(st) => SecState(Transform(e, st))) 

IMPORTING Sec theoryfAccess State, Transformlnstance, fs, SecState, 
Transform] 


END State 


State TCCs 

% Disjointness TCC generated (at line 47, column 6) for 
% COND a m = rd -> slSubject(a'u) >= slObject(a'f), 

% a m = wr -> slSubject(a'u) = slObject(a'f) 

% ENDCOND 
% proved - complete 

SecureAccess_TCCl: OBLIGATION FORALL (a: Access): NOT (a m = rd AND 
am = wr); 


% Coverage TCC generated (at line 47, column 6) for 
% COND a m = rd -> slSubject(a'u) >= slObject(a'f), 

% a m = wr -> slSubject(a'u) = slObject(a'f) 

% ENDCOND 
% proved - complete 

SecureAccess_TCC2: OBLIGATION FORALL (a: Access): a'm = rd OR a'm = wr; 

% Tbe disjointness TCC (at line 47, column 6) in decl SecureAccess for 
% COND a'm = rd -> slSubject(a'u) >= slObject(a'f), 

% a'm = wr -> slSubject(a'u) = slObject(a'f) 

% ENDCOND 

% was not generated because it simplifies to TRUE. 

% Tbe coverage TCC (at line 47, column 6) in decl SecureAccess for 
% COND a m = rd -> slSubject(a'u) >= slObject(a'f), 

% a m = wr -> slSubject(a'u) = slObject(a'f) 

% ENDCOND 

% was not generated because it simplifies to TRUE. 
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% Disjointness TCC generated (at line 57, column 6) for 

% COND e'ac = addit AND SecureAccess(e'a) -> add(e'a, st), 

% e'ac = del AND st(e'a) -> remove(e'a, st), 

% member(e'ac, no op) -> st, 

% ELSE -> st 
% ENDCOND 
% proved - complete 

Transform TCC 1: OBLIGATION 
FORALL (e: Transformlnstance, st: Access State): 

NOT ((e'ac = addit AND SecureAccess(e'a)) AND e'ac = del AND st(e'a)) AND 
NOT ((e'ac = addit AND SecureAccess(e'a)) AND member [Action] (e'ac, noop)) 
AND NOT ((e'ac = del AND st(e'a)) AND member [Action] (e'ac, noop)); 

% Tbe disjointness TCC (at line 57, column 6) in decl Transform for 
% COND e'ac = addit AND SecureAccess(e'a) -> add(e'a, st), 

% e'ac = del AND st(e'a) -> remove(e'a, st), 

% member(e'ac, no op) -> st, 

% ELSE -> st 
% ENDCOND 

% was not generated because it simplifies to TRUE, 

% Assuming TCC generated (at line 76, column 12) for 
% Sec_tbeory[Access_State, Transformlnstance, fs, SecState, Transform] 

% generated from assumption Sec tbeory.transition state secure 
% proved - complete 

IMP_Sec_theory TCCl: OBLIGATION 
FORALL (st: Access State, x: Transformlnstance): 

SecState(st) => SecState(Transform(x, st)); 

% Assuming TCC generated (at line 76, column 12) for 
% Sec_tbeory[Access_State, Transformlnstance, fs, SecState, Transform] 

% generated from assumption Sec_tbeory,seq_0_secure 
% proved - complete 

IMP Secjbeory TCC2: OBLIGATION SecState(nth[Access_State](fs, 0)); 

% Assuming TCC generated (at line 76, column 12) for 
% Sec_tbeory[Access_State, Transformlnstance, fs, SecState, Transform] 

% generated from assumption Sec tbeory.seq transform 
% proved - complete 

IMP_Sec_theory TCC3: OBLIGATION 
FORALL (n: nat): 

EXISTS (x: Transformlnstance): 

ntb[Access_State](fs, n + 1) = Transform(x, nth[Access_State](fs, n)); 
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Proofs for Sec theory and State Specifications 


Proof scripts for importchain of theory State: 


Sec_theory,seq_is_secure: proved - complete [shostak](0,50 s) 

(expand "every") 

(induct "n") 

(("1" (use "seq_0_secure")) 

(" 2 " 

(skolem!) 

(use "seq_transform") 

(skolem!) 

(use "transition state secure") 

(replace -2 (-1) rl) 

(propax)))) 


State.SecureAccess TCCl: proved - complete [shostak](3.68 s) 
("" (skolem!) (use "RdnotWr") (flatten) (simplify) (grind)) 


State.SecureAccess_TCC2: proved - complete [shostak](l,24 s) 

("" (skolem!) (typepred "a!l'm") (propax)) 

State.Transform TCCl: proved - complete [shostak](0,60 s) 

("" (skolem!) (use "AddDelNotNo Op") (use "AddnotDel") (grind)) 

State.IMP Sec theory TCCl: proved - complete [shostak](2,46 s) 
("" (skolem!) (use "transition state secure")) 

State,IMP_Sec_theory_TCC2: proved - complete [shostak](0.64 s) 
("" (use "fs O secure")) 
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State.IMP_Sec_theory_TCC3: proved - complete [shostak](2,90 s) 
("" (skolem!) (use "fs transform")) 
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APPENDIX N: FTLSSPEC SPECIFICATION 


FTLSSpec[Action: TYPE+, addit: Action, del: Action, no ops: setof[Action], 

Mode: TYPE+, rd: Mode, wr: Mode]: THEORY 
BEGIN 

IMPORTING SLabels 

% Axioms are used instead of assumptions since these principles should be satisfied 
% in the implementation 

AddDelNotNo_Ops: AXIOM 

NOT member(addit, no ops) AND NOT member(del, no ops) 

AdditNotDel: AXIOM NOT addit = del 

% Read and write are the modes 

ReadNotWr: AXIOM NOT rd = wr 

MAXMEM: nat 

Memory: TYPE+ = {mem: nat \ mem <= MAXMEM] CONTAINING MAXMEM 
MemoryExists: AXIOM EORALL (m: Memory): m> 0 

% A memory block is represented by lower and upper bound values of memory 

MemBlock: TYPE+ = [# lb: Memory, ub: (x: Memory \ x >= lb] #] CONTAINING (# 
lb := MAXMEM, ub:= MAXMEM#) 

SetofMB: TYPE+ = setoffMemBlock] CONTAINING (x: MemBlock \ x = 

(# lb := MAXMEM, ub := MAXMEM #)} 

slMemBlock: [MemBlock -> Label] 

% Verifies that memory block do not overlap 

ValidMemBlocks(smb: SetofMB): bool = 

EORALL (e, b: MemBlock): 

NOT e = b AND member(e, smb) AND member(b, smb) => 

(e'lb > b'ub) OR (b'lb > e'ub) 

% System memory blocks are memory blocks that are valid 

SystemMemBlocks: TYPE+ = (sysmb: SetofMB \ ValidMemBlocks(sysmb)} 
CONTAINING (x: MemBlock \x = (#lb := MAXMEM, ub := MAXMEM #)] 

% System memory is a fixed set of valid memory blocks 

SysMem: SystemMemBlocks 
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ProcessID: TYPE+ FROM nat 


% Each memory block instance has an associated mode 

MemBlockInstance: TYPE = 

f# mb: {x: MemBlock \ member(x, SysMem)}, m: Mode #J 
ProcessMB: TYPE = setof[MemBlockInstance] 

% Each process is associated with a ProcessID number and a set of memory blocks 
% with their associated modes 

Processes: TYPE = [ProcessID -> ProcessMB] 

slPr: [ProcessID -> Label] 

Request: TYPE = [# ac: Action, p: ProcessID, mbi: MemBlockInstance #] 

% Provides some inter-level mapping between the State specification and the FTLSSpec 
% specification 

IMPORTING State[ProcessID, MemBlock, slPr, slMemBlock, Action, addit, 
del, no ops. Mode, rd, wr] 

% Maps a component of FTLSSpec to Transformlnstance, a component of State 
% A Transformlnstance’s action corresponds to a request’s action, a subject corresponds 
% to a request’s processed, an object corresponds with a request’s memory block and a 
% mode corresponds with a request’s mode 

Proc_Trans_Inst(r: Request): Transformlnstance = 

(# ac := r'ac, a := (# u := r'p,f:= r'mbi'mb, m := r'mbi'm #) #) 


p: VAR Processes 

% Maps a component of FTLSSpec to Access _State, a component of the State 
% specification 

% Process State maps processes that map to an Access _State where for every access in 
% the Access_State there exists a memory block and ProcessID in which the access ’ 

% subject corresponds with a ProcessID and the access ’ object corresponds with a 
% memory block and the access ’ mode corresponds with the memory block’s mode and 
% the memory block is a member of that process associated with the ProcessID 
Process_State(p): Access_State = 

[a: Access \ EXISTS (mbi: MemBlockInstance, PID: ProcessID): 

a'u= PID AND af= mbi'mb AND a'm = mbi'm AND memberjmbi, p(PID))} 

% Verifies that a request is secure by checking the access privileges a memory block 
% and a process 

SecureRequest?(r: Request): bool = 

COND r'ac = addit -> 

((r'mbi'm = rd AND slPr(r'p) >= slMemBlock(r'mbi'mb)) OR 
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(r'mbi'm = wr AND slPr(r'p) = slMemBlock(r'mbi'mb))), 

ELSE -> TRUE 
ENDCOND 

% A memory block can be added to a process if it is part of a secure request. 

% A memory can be deleted from a process by just removing it from the process 

ProcTransformjr: Request, Pr: Processes): Processes = 

COND ac(r) = addit AND SecureRequest?(r) -> 

LAMBDA (x: ProcessID): 

IF NOT X = r 'p THENPr(x) ELSE addjr 'mbi, Pr(x)) ENDIF, 
r'ac = del -> 

LAMBDA (x: ProcessID): 

IF NOT X = r'p THEN Pr(x) ELSE removejr'mbi, Pr(x)) ENDIF, 
ELSE->Pr 
ENDCOND 

% Verifies that all memory blocks of a process satisfy the security properties then it is a 
% secure process 

SecProcessjp: Processes, pid: ProcessID): bool = 

FORALL (mbi: MemBlockInstance \ member(mbi, p(pid))): 

COND mbi'm = rd -> slPr(pid) >= slMemBlock(mbi'mb), 
mbi'm = wr -> slPr(pid) = slMemBlock(mbi'mb) 

ENDCOND 

% Verifies that if all processes are secure in the current state, then the state is secure 

SecProcesses(pr: Processes): bool = 

FORALL (pid: ProcessID): SecProcess(pr, pid) 

SecProcesses(pr) => SecProcesses(ProcTransform(r, pr))) 

END FTLSSpec 


FTLSSpec Specification TCCs 

% Subtype TCC generated (at line 16, column 56) for MAXMEM 
% expected type Memory 
% proved - complete 

Memory TCC 1: OBLIGATION MAXMEM <= MAXMEM; 

% Subtype TCC generated (at line 40, column 13) for 
% {x: MemBlock | x = (# lb := MAXMEM, ub := MAXMEM #)} 
% expected type SystemMemBlocks 
% proved - complete 

SystemMemBlocks_TCCl: OBLIGATION 
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ValidMemBlocks({x: MemBlock | x = (# lb := MAXMEM, ub := MAXMEM #)}); 

% Assuming TCC generated (at line 57, column 12) for 

% State[ProcessID, MemBlock, slPr, slMemBlock, Action, addit, del, 

% no ops. Mode, rd, wr] 

% generated from assumption State,AddDelNotNo_Op 
% proved - complete 
IMP_State_TCCl: OBLIGATION 

NOT member [Action] (addit, noops) AND NOT member [Action] (del, noops); 

% Assuming TCC generated (at line 57, column 12) for 

% State[ProcessID, MemBlock, slPr, slMemBlock, Action, addit, del, 

% no ops. Mode, rd, wr] 

% generated from assumption State,AddnotDel 
% proved - complete 

IMP State_TCC2: OBLIGATION NOT addit = del; 

% Assuming TCC generated (at line 57, column 12) for 

% State[ProcessID, MemBlock, slPr, slMemBlock, Action, addit, del, 

% no ops. Mode, rd, wr] 

% generated from assumption State.RdnotWr 
% proved - complete 

IMP State_TCC3: OBLIGATION NOT rd = wr; 

% Disjointness TCC generated (at line 79, column 6) for 
% COND r'ac = addit AND SecureRequest?(r) -> 

% LAMBDA (x: ProcessID): 

% IF NOT X = r'p THEN Pr(x) ELSE add(r'mbi, Pr(x)) ENDIF, 

% r'ac = del-> 

% LAMBDA (x: ProcessID): 

% IF NOT X = r'p THEN Pr(x) ELSE remove(r'mbi, Pr(x)) ENDIF, 

% ELSE -> Pr 
% ENDCOND 
% proved - incomplete 
ProcTransform TCCl: OBLIGATION 
FORALL (r: Request): 

NOT ((r'ac = addit AND SecureRequest?(r)) AND r'ac = del); 

% The disjointness TCC (at line 79, column 6) in decl ProcTransform for 
% COND r'ac = addit AND SecureRequest?(r) -> 

% LAMBDA (x: ProcessID): 

% IF NOT X = r'p THEN Pr(x) ELSE add(r'mbi, Pr(x)) ENDIF, 

% r'ac = del-> 

% LAMBDA (x: ProcessID): 

% IF NOT X = r'p THEN Pr(x) ELSE remove(r'mbi, Pr(x)) ENDIF, 

% ELSE -> Pr 
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% ENDCOND 

% was not generated because it simplifles to TRUE, 

% Disjointness TCC generated (at line 92, column 8) for 
% COND mbi'm = rd -> slPr(pid) >= slMemBlock(mbi'mb), 

% mbi'm = wr -> slPr(pid) = slMemBlock(mbi'mb) 

% ENDCOND 
% proved - incomplete 

SecProcess_TCCl: OBLIGATION 
FORALL (p: Processes, pid: ProcessID, 

mbi: MemBlockInstance | member[MemBlockInstance](mbi, p(pid))): 
NOT (mbi'm = rd AND mbi'm = wr); 

% Tbe disjointness TCC (at line 92, column 8) in decl SecProcess for 
% COND mbi'm = rd -> slPr(pid) >= slMemBlock(mbi'mb), 

% mbi'm = wr -> slPr(pid) = slMemBlock(mbi'mb) 

% ENDCOND 

% was not generated because it simplifies to TRUE, 

% Tbe coverage TCC (at line 92, column 8) in decl SecProcess for 
% COND mbi'm = rd -> slPr(pid) >= slMemBlock(mbi'mb), 

% mbi'm = wr -> slPr(pid) = slMemBlock(mbi'mb) 

% ENDCOND 

% was not generated because it simplifies to TRUE, 


Proof Commands for FTLSSpec Specification 


Proof scripts for importcbain of theory FTLSSpec: 


Sec_tbeory,seq_is_secure: unchecked [shostak](5,29 s) 

(expand "every") 

(induct "n") 

(("1" (use "seq O secure")) 

(" 2 " 

(skolem!) 

(use "seq transform") 

(skolem!) 

(use "transition state secure") 

(replace -2 (-1) rl) 
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(propax)))) 


State.SecureAccess TCCl: proved - complete [shostak](3,68 s) 

("" (skolem!) (use "RdnotWr") (flatten) (simplify) (grind)) 

State,SecureAccess_TCC2: proved - complete [shostak](1.24 s) 

("" (skolem!) (typepred "all'm") (propax)) 

State.Transform TCCl: proved - complete [shostak](0,60 s) 

("" (skolem!) (use "AddDelNotNo Op") (use "AddnotDel") (grind)) 

FTLSSpec.Memory TCCl: proved - complete [shostak](0,03 s) 

("" (tcc)) 

FTLSSpec.SystemMemBlocks TCCl: proved - complete [shostak](0,14 s) 
("" (tcc)) 

FTLSSpecJMP State TCCl: proved - complete [shostak](0,03 s) 

("" (use "AddDelNotNo Ops")) 

FTLSSpec,IMP_State_TCC2: proved - complete [shostak](0,07 s) 

("" (tcc) (use "AdditNotDel")) 

FTLSSpec,IMP_State_TCC3: proved - complete [shostak](0.72 s) 

("" (use "ReadNotWr")) 

FTLSSpec.ProcTransform TCCl: proved - complete [shostak](0,15 s) 

("" (skolem!) (flatten) (use "AdditNotDel") (grind)) 
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FTLSSpec.SecProcess TCCl: proved - complete [shostak](0.09 s) 
("" (skolem!) (use "ReadNotWr") (grind)) 
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APPENDIX O: PROOF OF THEOREM SEQ_IS_SECURE OF 
SEC SPECIFICATION 


seq_is_secure : 


{1} every(SecState)(seq) 

Rerunning step: (expand "every") 
Expanding the definition of every, 
this simplifies to: 
seq is secure : 


{1} FORALL n: SecState(nth(seq, n)) 

Rerunning step: (induct "n") 
Inducting on n on formula 1, 
this yields 2 suhgoals: 
seq is secure.l : 


{1} SecState(nth(seq, 0)) 

Rerunning step: (use "seq_0_secure") 

Using lemma seq O secure, 

This completes the proof of seq_is_secure.l. 

seq_is_secure.2 : 


{1} FORALL j: SecState(nth(seq, j)) IMPLIES SecState(nth(seq, j + 1)) 

Rerunning step: (skolem!) 

Skolemizing, 
this simplifies to: 
seq_is_secure.2 : 


{1} SecState(nth(seq, j!l)) IMPLIES SecState(nth(seq, j! 1 + 1)) 

Rerunning step: (use "seq_transform") 

Using lemma seq transform, 
this simplifies to: 
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seq_is_secure,2 : 

{-1} EXISTS x: nth($eq, j!l + 1) = Transform(x, nth(seq, j!l)) 


[1] SecState(nth(seq, j!l)) IMPLIES SecState(nth(seq, j! 1 + 1)) 

Rerunning step: (skolem!) 

Skolemizing, 
this simplifies to: 
seq_is_secure.2 : 

{-1} nth(seq, j!l + 1) = Transform(x!l, nth(seq, j!l)) 


[1] SecState(nth(seq, j! 1)) IMPLIES SecState(nth(seq, j! 1 + 1)) 

Rerunning step: (use "transition state secure") 

Using lemma transition state secure, 
this simplifies to: 
seq_is_secure,2 : 

{-1} SecState(nth(seq, j!l)) => SecState(Transform(x!l, nth(seq, j!l))) 
[-2] nth(seq, j!l + 1) = Transform(x!l, nth(seq, j!l)) 


[1] SecState(nth(seq, j! 1)) IMPLIES SecState(nth(seq, j! 1 + 1)) 

Rerunning step: (replace -2 (-1) rl) 

Replacing using formula -2, 
this simplifies to: 
seq_is_secure,2 : 

{-1} SecState(nth(seq, j!l)) => SecState(nth(seq, j! 1 + 1)) 

[-2] nth(seq, j!l + 1) = Transform(x!l, nth(seq, j!l)) 


[1] SecState(nth(seq, j!l)) IMPLIES SecState(nth(seq, j! 1 + 1)) 
which is trivially true. 

This completes the proof of seq_is_secure.2, 

Q.E.D, 


Run time = 0,88 secs. 
Real time = 1.39 secs. 
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GLOSSARY 



DEFINITION 

Abstract data types 

An abstract data type (ADT) is characterized by the 
following properties: (1) It exports a type. (2) It exports a set 
of operations. This set is called interface. (3) Operations of 
the interface are the one and only access mechanism to the 
type's data structure. (4) Axioms and preconditions define 
the application domain of the type. 

BDDs(Binary Decision 
Diagrams) 

BDDs are a canonical and efficient way to represent and 
manipulate Boolean functions 

Dependent type 

A dependent type is a type consisting of several components 
where the type of (or the domain of a later component 
depends on other earlier components 

Equational logic 

First-order equational logic consists of quantifier-free terms 
of ordinary first-order logic, with equality as the only 
predicate symbol 

Executable formal 
specification 

Executable formal specification can allow engineers to test 
(or simulate) the specified system on concrete data before 
the system is implemented 

First order predicate logic 

Predicate logic in which predicates take only individuals as 
arguments and quantifiers only bind individual variables. 

Higher order predicate 
logic 

Predicate logic in which predicates take other predicates as 
arguments and quantifiers bind predicate variables 

Inductive theorem prover 

Theorem prover with induction that is based on the explicit 
induction paradigm 

Inductively defined 
predicates 

Inductively defined predicates have several properties that 
can be used when formally proving theorems on the 
predicates: (I) The theorem that the predicate P satisfies the 
given rules (2) The induction theorem obtained from the fact 
that P is the least relation (3) The case analysis theorem on 

P 

Logical Framework 

The idea of a logical framework is to provide a single, 
universal formalism for representing formalisms so that an 
implementation of a formal system may be obtained by 
simply representing it in the framework 

Model Checker 

A technique used to detect errors or prove the absence in 
safety critical software and hardware systems; Based on the 
optimization of datastructure and algorithms 

Predicate subtypes 

A predicate subtype is a subtype defined by requiring the 
elements of the subtype to satisfy a predicate 
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DEFINITION 

Proof checker 

A proof checker consists of "a system of language for 
mathematics" and "a program to check the proof written in 
such a language". 

Propositional logic 

Propositional Logic is concerned with propositions and their 
interrelationships. Roughly speaking, a proposition is a 
possible "condition " of the world about which we want to 
say something 

Quantifier free 

A formula is quantifier free if and only if it contains no 
quantifiers 

Recursively defined 
abstract data types 

Abstract data structures that are "tree-like" recursive data 
structures (i.e. lists and binary trees) 

Semantic subtype 

A semantic subtype is a subtype such that the set of the 
objects represented by the terms of the subtype is a subset of 
the objects represented by the terms of the parent type 

Subtyping 

If for every object ol: S there is o2:T such that for all 
programs P defined in terms of T, the behavior of P is 
unchanged when ol is substituted for o2, then S is a subtype 

ofT. 

Syntactic subtype 

A syntactic subtype is a subtype such that the set of the 
syntactic elements (terms) of the subtype is a subset of the 
syntactic elements of the parent type 

Theorem prover 

A tool necessary to check and to manage proofs. It can come 
with decision procedures and other automated deduction 
which can make the proof much quicker and easier. The 
theorem prover is closely related to a proof checker since 
both are about "mechanical reasoning. The difference is 
whether the focus is on the computer checking the reasoning 
of the human, or on the human watching and guiding the 
computer's proof efforts. The more a system tries to be 
"smart", the more chance it has of being in the "theorem 
prover" category. 
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